Diagram with configurable wires

ABSTRACT

Configuring wires/icons in a diagram. The diagram may be an executable diagram such as a graphical program or a system diagram. The diagram may include a plurality of icons that are connected by wires, and the icons may visually represent functionality of the diagram. The diagram may be executable to perform the functionality. Displaying the diagram may include displaying a first wire in the diagram, where the first wire connects a first icon and a second icon. Data transfer functionality may be specified for the first wire and/or the first or second icon in the diagram. The data transfer functionality may be visually indicated in the diagram, e.g., by appearances of the first icon, the second icon, the first wire, and/or icons displayed proximate to these components of the diagram.

PRIORITY CLAIM

This application is a continuation in part of U.S. patent applicationSer. No. 11/462,393 titled “Asynchronous Wires for GraphicalProgramming”, filed Aug. 4, 2006, whose inventors were Jeffrey L.Kodosky and Jacob Kornerup, which is hereby incorporated by reference inits entirety as though fully and completely set forth herein.

FIELD OF THE INVENTION

The present invention relates to the field of graphical programming, andmore particularly to a system and method for wire configuration in adiagram.

DESCRIPTION OF THE RELATED ART

In data flow based graphical programs, the wires used to communicatebetween graphical program nodes (which may themselves be or representgraphical programs) are subject to data flow rules or protocols. Forexample, in graphical programs that are data flow diagrams, a node willnot execute or “fire” until all necessary data inputs to the node arepresent. Thus communication between nodes via current data flow wires isconstrained to be synchronous, which may limit the functionality andexecution of graphical programs. This is especially true for diagramsthat include multiple (substantially) concurrently executing portions,e.g., nodes, VIs, sub-VIs, or other graphical program elements orconstructs, which may be referred to herein generally as nodes. In someprior art approaches to communication between nodes, variables, such aslocal or global variables, or queues, may be used to pass data back andforth between the nodes. For example, applications that includeconcurrent loops that communicate with each other typically requirequeues or global variables to transfer data between the loops. However,there is currently no graphical way of depicting this connection, andmoreover, it is not very convenient to construct. For example, usingglobal variables only provides the name association, and using built-inqueues involves a non-intuitive construction where the queue isallocated at the top level diagram and the reference is passed down bothto the writer and to the reader.

FIG. 1 illustrates communication between two while loops 102 and 104 viaa shared variable, where, as may be seen, a random number is generatedby a first node 103 represented by an icon of a pair of dice andcontained in the top while loop 102, and placed in or written to anumeric variable, labeled “numeric”. The numeric variable is thenaccessed or read by a second node 105, in this case, an add node (atriangle node labeled “+1”, contained in the bottom while loop 104), andthe value incremented by 1, and the result displayed (as a double).

As may be seen, there is no explicit indication of the variable-basedmeans for communicating between the while loops. Thus, for programnodes, elements, etc., that are not placed near one another, it may notbe clear that such communication is occurring or accommodated, possiblyleading to confusion, and/or programming or operational errors.

Thus, improved means for communications between graphical program nodesare desired.

SUMMARY OF THE INVENTION

Various embodiments are presented of a diagram with configurable wires.

A diagram may be displayed on a display which includes a plurality oficons connected by wires. The plurality of interconnected icons mayvisually represent functionality of the diagram, and the diagram may beexecutable to perform the functionality. The diagram may be a graphicalprogram or system diagram. The icons may represent software functions(e.g., similar to nodes in a graphical program) or may representdevices, as desired. For example, the icons in the diagram may representlogical elements, processing elements, configurable elements, and/orother devices/functions. Thus, in one embodiment, the diagram mayinclude a data flow diagram, where the icons represent functions and thewires indicate that data produced by one icon is used by another icon.Additionally, the diagram may also include one or more processingelements or icons which represent devices for executing the nodes orfunctions. In some embodiments, the nodes executed by a device may berepresented as a plurality of interconnected nodes or icons (e.g., agraphical program portion) that is included within a target executionicon which represents a device. Displaying the diagram may includedisplaying a first wire connecting a first icon and a second icon in thediagram.

The first wire or icon(s) may be configured. Configuring the wire oricon may include specifying data transfer functionality of the wire oricon. For example, configuring the wire or icon may includespecification of data exchange semantics, data transport protocols, datatransport mediums, and/or other specifications related to datatransfers. The data exchange semantics may include the method by whichthe data may be transferred, e.g., using a circular buffer, register,queues, and/or other buffered semantics. The data transport protocol mayspecify a method for implementing the data exchange semantics for thefirst wire. For example, the data transport protocol may be the specificprotocol used to transmit the data over the data transport medium (e.g.,the networked connection, the PCI bus, etc.). Exemplary data transportprotocols include TCP/IP, USB, DMA, register access, etc. Data transportmediums indicate the medium by which the data is transferred, e.g.,physical media such as wires, busses, Ethernet, etc., and/or wirelessmeans.

Configuring the wire or icon may also include specifying read or writepolicies for the first wire or icon, specifying directionality of thewire (e.g., the direction of data flow), semantics of wire branching,and/or specification of data structures associated with the first wireor icon. Additionally, the data transport protocol may be adapted to thedata exchange semantics, e.g., by combining program logic with the datatransport protocol to implement the data exchange semantics. In oneembodiment, configuration of the wire or icon may include configuringthe wire to provide transport status information. Thus, configuring thewire or icon may include specification of communication behavior for thefirst wire or icon(s).

In some embodiments, configuring the wire or icon may be performedautomatically or manually as desired. Automatic configuration of thefirst wire or icon may be completely automatic (i.e., without any userinput specifying the configuration) or partially automatic. For example,the user may specify data exchange semantics for the first wire or icon,and the data transport protocol and/or data transport medium for thedata transfer may be automatically determined and specified for thefirst wire or icon. Similarly, any combination of the data transferfunctionality (e.g., the semantics, protocol, or medium) may beautomatically determined using the semantics, protocol, and/or mediumalready specified by the user. However, as noted above, the entireconfiguration may be performed automatically. Note that automaticdetermination of portions of the data transfer functionality (e.g., thedata transport protocol) may be determined based on the communicationproperties (e.g., the communication policies) of the first wire and/orthe endpoints (e.g., the icons) of the first wire.

Configuring the first wire or icon may include the user selecting thefirst wire or icon, and then configuring the first wire or icon using agraphical user interface (GUI) or a series of GUIs (e.g., a wizard).Additionally, or alternatively, configuring the first wire or icon mayinclude specification of a graphical program which describes the datatransfer functionality of the first wire or icon. In some embodiments,the user may select and/or configure the wire or icon by selecting anaffordance of the wire. The affordance of the wire may be an icondisplayed on or proximate to the wire or icon, or may be the entirety ofthe wire or icon, among other options.

In some embodiments, configuring the first wire or icon may includeassociating an already configured icon or wire with the first wire oricon. For example, the user may simply drag an already configured wireor icon onto the first wire or icon to configure the first wire or icon.In one embodiment, the user may select preconfigured wires or icons(e.g., data transfer icons) and use those icons to configure or connecticons in the diagram, thereby associating data transfer functionalitywith the icons or wires in the diagram.

After configuration, the first wire or icon may visually indicate thatdata from the first icon is provided to the second icon according to thedata transfer functionality (e.g., the data exchange semantics specifiedduring configuring of the first wire). For example, the first wire oricon may take on a new appearance after configuration indicating thespecified configuration. For example, the first wire may take on apattern, color, and/or thickness which indicates the configuration ofthe first wire. Additionally, the visual appearances of the wire (whichindicate various different configurations) may include a 3D appearance,a tube appearance, a separated appearance, and/or a curved appearance(e.g., in addition to the patterns, colors, and/or thicknesses describedabove). Thus, the first wire may visually indicate the configuration ofthe first wire.

Alternatively, a data transfer icon (or data transfer indicator) may bedisplayed proximate to the wire to visually indicate the data transferfunctionality of the wire. In some embodiments, the data transfer iconmay be an affordance for the first wire, e.g., which may be used toconfigure the first wire. The data transfer icon may represent acircular buffer (e.g., including at least one circle and arrow), a FIFO(e.g., including a plurality of rectangles and an arrow), a register, amailbox (e.g., including at least one rectangle and an arrow), and/orother semantics/appearances.

In some embodiments, where the icon is configured, the icon may take ona similarly take on a new appearance, or a data transfer icon/indicatormay be displayed proximate to the icon. In one embodiment, the datatransfer icon may be connected to the first icon via the first wire.Alternatively, the data transfer icon may be included within the firsticon.

The diagram may be executed after configuration. During execution of thediagram, the data transfer functionality may be performed as specifiedby the first wire. For example, where the first wire specifies datatransfer between two devices, the data may be transferred between thetwo devices as stipulated by the configured wire. Where the first wirespecifies data transfer between two or more functions or code portionsexecuting on a computer a system, the data transfer may be performed asspecified for the first wire. Thus, during execution, the diagram may beexecuted according to the configured data transfer functionality of thefirst wire.

BRIEF DESCRIPTION OF THE DRAWINGS

A better understanding of the present invention can be obtained when thefollowing detailed description of the preferred embodiment is consideredin conjunction with the following drawings, in which:

FIG. 1 illustrates a graphical program with communication between twowhile loops via a shared variable, according to the prior art;

FIG. 2A illustrates a computer system operable to execute a diagramaccording to an embodiment of the present invention;

FIG. 2B illustrates a network system comprising two or more computersystems that may implement an embodiment of the present invention;

FIG. 3A illustrates an instrumentation control system according to oneembodiment of the invention;

FIG. 3B illustrates an industrial automation system according to oneembodiment of the invention;

FIG. 4A is a high-level block diagram of an exemplary system which mayexecute or utilize diagrams;

FIG. 4B illustrates an exemplary system that may perform control and/orsimulation functions utilizing diagrams;

FIG. 5 is an exemplary block diagram of the computer systems of FIGS.2A, 2B, 3A and 3B and 4B;

FIGS. 6A and 6B are screen shots of an exemplary graphical programaccording to one embodiment;

FIG. 7A is a screen shot of an exemplary system diagram whichcorresponds to FIGS. 6A and 6B;

FIGS. 7B-7D are screen shots of an exemplary system diagram according toone embodiment;

FIGS. 8A and 8B are screen shots of a split view of a system diagram anda physical diagram according to one embodiment;

FIGS. 9A and 9B are screen shots of a composite view of a system diagramand a physical diagram according to one embodiment;

FIG. 10 is a flowchart diagram illustrating one embodiment of a methodfor configuring wires in a diagram;

FIG. 11 is a flowchart diagram illustrating one embodiment of a methodfor automatically determining a data transport protocol for a wire witha data exchange semantic;

FIG. 12 is a flowchart diagram illustrating one embodiment of a methodfor displaying wires which visually represent their data exchangesemantics;

FIG. 13 is a flowchart diagram illustrating one embodiment of a methodfor configuring data transport icons associated with a node in adiagram;

FIG. 14 is a flowchart diagram illustrating one embodiment of a methodfor displaying data transport indicators which visually indicate datatransfer functionality;

FIGS. 15A-15E are exemplary screen shots of GUIs for configuring a wireor data transfer icon according to one embodiment;

FIGS. 16A-16J are exemplary icons which may be used for indicating orconfiguring configurable wires according to one embodiment;

FIGS. 17A-17H are exemplary wires with icons for indicating orconfiguring configurable wires according to one embodiment;

FIG. 18 is a flowchart diagram illustrating one embodiment of a methodfor asynchronous communication in a graphical program;

FIG. 19 is graphical program illustrating use of asynchronous wires,according to one embodiment;

FIG. 20 illustrates one embodiment of an exemplary graphical programthat includes two separately executable while loops with respectivenodes coupled via an asynchronous wire;

FIG. 21 illustrates one embodiment of an exemplary signal processinggraphical program with multiple asynchronous wires;

FIG. 22 illustrates exemplary output from the signal processinggraphical program of FIG. 21; and

FIG. 23 illustrates an exemplary embodiment of a downsample node fromthe graphical program of FIG. 21, where asynchronous I/O for the node isimplemented via queues.

While the invention is susceptible to various modifications andalternative forms, specific embodiments thereof are shown by way ofexample in the drawings and are herein described in detail. It should beunderstood, however, that the drawings and detailed description theretoare not intended to limit the invention to the particular formdisclosed, but on the contrary, the intention is to cover allmodifications, equivalents and alternatives falling within the spiritand scope of the present invention as defined by the appended claims.

DETAILED DESCRIPTION OF THE EMBODIMENTS Incorporation by Reference

The following references are hereby incorporated by reference in theirentirety as though fully and completely set forth herein:

U.S. Pat. No. 5,481,741 titled “Method and Apparatus for ProvidingAttribute Nodes in a Graphical Data Flow Environment”.

U.S. Pat. No. 6,173,438 titled “Embedded Graphical Programming System”filed Aug. 18, 1997.

U.S. Pat. No. 6,219,628 titled “System and Method for Configuring anInstrument to Perform Measurement Functions Utilizing Conversion ofGraphical Programs into Hardware Implementations,” filed Aug. 18, 1997.

U.S. Pat. No. 6,763,515, titled “System and Method for AutomaticallyGenerating a Graphical Program to Perform an Image ProcessingAlgorithm,” filed Jun. 5, 2000.

U.S. Patent Application Publication No. 2001/0020291 (Ser. No.09/745,023) titled “System and Method for Programmatically Generating aGraphical Program in Response to Program Information,” filed Dec. 20,2000.

U.S. patent application Ser. No. 11/462,393, titled “Asynchronous Wiresfor Graphical Programming”, filed Aug. 4, 2006.

U.S. Pat. No. 7,042,469, titled “Multiple Views for a Measurement SystemDiagram,” filed Dec. 23, 2002.

U.S. Patent Application Publication No. 2007/0044030, titled “GraphicalProgramming Methods for Generation, Control and Routing of DigitalPulses,” filed Aug. 8, 2006.

U.S. Provisional Ser. No. 60/869,221, titled “System Diagram thatIllustrates Programs in a Distributed System Having Multiple Targets,”filed Dec. 8, 2006.

U.S. Provisional Ser. No. 60/821,512, titled “Execution Target StructureNode for a Graphical Program,” filed Aug. 4, 2006.

U.S. application Ser. No. 10/893,745, titled Graphically RepresentingTiming in a Graphical Program, filed Jul. 16, 2004.

Terms

The following is a glossary of terms used in the present application:

Memory Medium—Any of various types of memory devices or storage devices.The term “memory medium” is intended to include an installation medium,e.g., a CD-ROM, floppy disks 104, or tape device; a computer systemmemory or random access memory such as DRAM, DDR RAM, SRAM, EDO RAM,Rambus RAM, etc.; or a non-volatile memory such as a magnetic media,e.g., a hard drive, or optical storage. The memory medium may compriseother types of memory as well, or combinations thereof. In addition, thememory medium may be located in a first computer in which the programsare executed, or may be located in a second different computer whichconnects to the first computer over a network, such as the Internet. Inthe latter instance, the second computer may provide programinstructions to the first computer for execution. The term “memorymedium” may include two or more memory mediums which may reside indifferent locations, e.g., in different computers that are connectedover a network.

Carrier Medium—a memory medium as described above, as well as a physicaltransmission medium, such as a bus, network, and/or other physicaltransmission medium that conveys signals such as electrical,electromagnetic, or digital signals.

Programmable Hardware Element—includes various hardware devicescomprising multiple programmable function blocks connected via aprogrammable interconnect. Examples include FPGAs (Field ProgrammableGate Arrays), PLDs (Programmable Logic Devices), FPOAs (FieldProgrammable Object Arrays), and CPLDs (Complex PLDs). The programmablefunction blocks may range from fine grained (combinatorial logic or lookup tables) to coarse grained (arithmetic logic units or processorcores). A programmable hardware element may also be referred to as“reconfigurable logic”.

Program—the term “program” is intended to have the full breadth of itsordinary meaning The term “program” includes 1) a software program whichmay be stored in a memory and is executable by a processor or 2) ahardware configuration program useable for configuring a programmablehardware element.

Software Program—the term “software program” is intended to have thefull breadth of its ordinary meaning, and includes any type of programinstructions, code, script and/or data, or combinations thereof, thatmay be stored in a memory medium and executed by a processor. Exemplarysoftware programs include programs written in text-based programminglanguages, such as C, C++, Pascal, Fortran, Cobol, Java, assemblylanguage, etc.; graphical programs (programs written in graphicalprogramming languages); assembly language programs; programs that havebeen compiled to machine language; scripts; and other types ofexecutable software. A software program may comprise two or moresoftware programs that interoperate in some manner.

Hardware Configuration Program—a program, e.g., a netlist or bit file,that can be used to program or configure a programmable hardwareelement.

Diagram—A graphical image displayed on a computer display which visuallyindicates relationships between graphical elements in the diagram.Diagrams may include configuration diagrams, system diagrams, physicaldiagrams, and/or graphical programs (among others). In some embodiments,diagrams may be executable to perform specified functionality, e.g.,measurement or industrial operations, which is represented by thediagram. Executable diagrams may include graphical programs (describedbelow) where icons connected by wires illustrate functionality of thegraphical program. Alternatively, or additionally, the diagram maycomprise a system diagram which may indicate functionality and/orconnectivity implemented by one or more devices. Various graphical userinterfaces (GUIs), e.g., front panels, may be associated with thediagram.

Graphical Program—A program comprising a plurality of interconnectednodes or icons, wherein the plurality of interconnected nodes or iconsvisually indicate functionality of the program. A graphical program is atype of diagram.

The following provides examples of various aspects of graphicalprograms. The following examples and discussion are not intended tolimit the above definition of graphical program, but rather provideexamples of what the term “graphical program” encompasses:

The nodes in a graphical program may be connected in one or more of adata flow, control flow, and/or execution flow format. The nodes mayalso be connected in a “signal flow” format, which is a subset of dataflow.

Exemplary graphical program development environments which may be usedto create graphical programs include LabVIEW, DasyLab, DiaDem andMatrixx/SystemBuild from National Instruments, Simulink from theMathWorks, VEE from Agilent, WiT from Coreco, Vision Program Managerfrom PPT Vision, SoftWIRE from Measurement Computing, Sanscript fromNorthwoods Software, Khoros from Khoral Research, SnapMaster from HEMData, VisSim from Visual Solutions, ObjectBench by SES (Scientific andEngineering Software), and VisiDAQ from Advantech, among others.

The term “graphical program” includes models or block diagrams createdin graphical modeling environments, wherein the model or block diagramcomprises interconnected nodes or icons that visually indicate operationof the model or block diagram; exemplary graphical modeling environmentsinclude Simulink, SystemBuild, VisSim, Hypersignal Block Diagram, etc.

A graphical program may be represented in the memory of the computersystem as data structures and/or program instructions. The graphicalprogram, e.g., these data structures and/or program instructions, may becompiled or interpreted to produce machine language that accomplishesthe desired method or process as shown in the graphical program.

Input data to a graphical program may be received from any of varioussources, such as from a device, unit under test, a process beingmeasured or controlled, another computer program, a database, or from afile. Also, a user may input data to a graphical program or virtualinstrument using a graphical user interface, e.g., a front panel.

A graphical program may optionally have a GUI associated with thegraphical program. In this case, the plurality of interconnected nodesare often referred to as the block diagram portion of the graphicalprogram.

Data Flow Graphical Program (or Data Flow Diagram)—A graphical programor diagram comprising a plurality of interconnected nodes, wherein theconnections between the nodes indicate that data produced by one node isused by another node.

Physical Diagram—A diagram which visually indicates physicalconnectivity between physical devices. For example, a physical diagrammay visually indicate the connectivity of various physical components ina measurement system, e.g., a computer connected to a measurement devicevia an Ethernet network. Thus the wires in a physical diagram representphysical connectivity between devices. A physical diagram may show thecorresponding “real world” physical system/devices.

Configuration Diagram—A diagram which indicates connectivity betweenreal and/or virtual devices. A configuration diagram may visuallyindicate physical connectivity between physical devices as shown in aphysical diagram. However, in some embodiments, one or more of thedevices (or all of the devices) in the configuration diagram may bevirtual or simulated devices. Thus, some or all of the devices in theconfiguration diagram may not be physically present in the systemrepresented by the configuration diagram.

System Diagram—A diagram with one or more device icons and graphicalprogram code, wherein the device icons are use to specify and/orvisually indicate where different portions of graphical program code aredeployed/executed. A system diagram may indicate where (i.e., on whichsystem/device) programs or code may be executed. For example, the systemdiagram may include graphical indications showing where portions of thedisplayed graphical program code are executed. In some embodiments,various ones of the icons may represent processing elements which haveassociated programs for execution. At least one of the icons mayrepresent logical elements (e.g., executable software functions orgraphical program code). One or more of the device icons may representconfigurable elements. Thus, the system diagram may provide a systemview which allows a user to easily understand where graphical programcode is deployed among the various devices in the system.

Node—In the context of a graphical program, an element that may beincluded in a graphical program. The graphical program nodes (or simplynodes) in a graphical program may also be referred to as blocks. A nodemay have an associated icon that represents the node in the graphicalprogram, as well as underlying code and/or data that implementsfunctionality of the node. Exemplary nodes (or blocks) include functionnodes, sub-program nodes (sub-Vis), terminal nodes, structure nodes,etc. Nodes may be connected together in a graphical program byconnection icons or wires. The term “logical element” is used herein torefer to a “node”. For example, the term “logical element: may refer toa software program portion or code that is executable by (orimplementable on) a processing element, and which is representediconically on a display. Logical elements include virtual instruments(VIs), primitives, etc. Logical elements may be displayed in variousones of the diagrams described herein, e.g., in graphical programs,system diagrams, etc.

Wire—a graphical element displayed in a diagram on a display thatconnects icons or nodes in the diagram. The diagram may be a graphicalprogram (where the icons correspond to software functions), a systemdiagram (where the icons may correspond to hardware devices or softwarefunctions), etc. The wire is generally used to indicate, specify, orimplement communication between the icons. Wires may represent logicaldata transfer between icons, or may represent a physical communicationmedium, such as Ethernet, USB, etc. Wires may implement and operateunder various protocols, including data flow semantics, non-data flowsemantics, etc. Some wires, e.g., buffered data transfer wires, may beconfigurable to implement or follow specified protocols or semantics.Wires may indicate communication of data, timing information, statusinformation, control information, and/or other information betweenicons. In some embodiments, wires may have different visual appearanceswhich may indicate different characteristics of the wire (e.g., type ofdata exchange semantics, data transport protocols, data transportmediums, and/or type of information passed between the icons, amongothers).

Graphical User Interface—this term is intended to have the full breadthof its ordinary meaning. The term “Graphical User Interface” is oftenabbreviated to “GUI”. A GUI may comprise only one or more input GUIelements, only one or more output GUI elements, or both input and outputGUI elements.

The following provides examples of various aspects of GUIs. Thefollowing examples and discussion are not intended to limit the ordinarymeaning of GUI, but rather provide examples of what the term “graphicaluser interface” encompasses:

A GUI may comprise a single window having one or more GUI Elements, ormay comprise a plurality of individual GUI Elements (or individualwindows each having one or more GUI Elements), wherein the individualGUI Elements or windows may optionally be tiled together.

A GUI may be associated with a diagram, e.g., a graphical program. Inthis instance, various mechanisms may be used to connect GUI Elements inthe GUI with nodes or icons in the diagram/graphical program. Forexample, when Input Controls and Output Indicators are created in theGUI, corresponding nodes (e.g., terminals) may be automatically createdin the diagram or graphical program. Alternatively, the user can placeterminal nodes in the diagram which may cause the display ofcorresponding GUI Elements front panel objects in the GUI, either atedit time or later at run time. As another example, the GUI may compriseGUI Elements embedded in the block diagram portion of the graphicalprogram.

Front Panel—A Graphical User Interface that includes input controls andoutput indicators, and which enables a user to interactively control ormanipulate the input being provided to a program or diagram, and viewoutput of the program or diagram, during execution.

A front panel is a type of GUI. A front panel may be associated with adiagram or graphical program as described above.

In an instrumentation application, the front panel can be analogized tothe front panel of an instrument. In an industrial automationapplication the front panel can be analogized to the MMI (Man MachineInterface) of a device. The user may adjust the controls on the frontpanel to affect the input and view the output on the respectiveindicators.

Graphical User Interface Element—an element of a graphical userinterface, such as for providing input or displaying output. Exemplarygraphical user interface elements comprise input controls and outputindicators

Input Control—a graphical user interface element for providing userinput to a program. Exemplary input controls comprise dials, knobs,sliders, input text boxes, etc.

Output Indicator—a graphical user interface element for displayingoutput from a program. Exemplary output indicators include charts,graphs, gauges, output text boxes, numeric displays, etc. An outputindicator is sometimes referred to as an “output control”.

Computer System—any of various types of computing or processing systems,including a personal computer system (PC), mainframe computer system,workstation, network appliance, Internet appliance, personal digitalassistant (PDA), television system, grid computing system, or otherdevice or combinations of devices. In general, the term “computersystem” can be broadly defined to encompass any device (or combinationof devices) having at least one processor that executes instructionsfrom a memory medium.

Measurement Device—includes instruments, data acquisition devices, smartsensors, and any of various types of devices that are operable toacquire and/or store data. A measurement device may also optionally befurther operable to analyze or process the acquired or stored data.Examples of a measurement device include an instrument, such as atraditional stand-alone “box” instrument, a computer-based instrument(instrument on a card) or external instrument, a data acquisition card,a device external to a computer that operates similarly to a dataacquisition card, a smart sensor, one or more DAQ or measurement cardsor modules in a chassis, an image acquisition device, such as an imageacquisition (or machine vision) card (also called a video capture board)or smart camera, a motion control device, a robot having machine vision,and other similar types of devices. Exemplary “stand-alone” instrumentsinclude oscilloscopes, multimeters, signal analyzers, arbitrary waveformgenerators, spectroscopes, and similar measurement, test, or automationinstruments.

A measurement device may be further operable to perform controlfunctions, e.g., in response to analysis of the acquired or stored data.For example, the measurement device may send a control signal to anexternal system, such as a motion control system or to a sensor, inresponse to particular data. A measurement device may also be operableto perform automation functions, i.e., may receive and analyze data, andissue automation control signals in response.

Processing Element—A hardware component or device which is operable toexecute software, implement code (e.g., program code), be configuredaccording to a hardware description, etc. Processing elements includevarious processors and/or programmable hardware elements (e.g., fieldprogrammable gate arrays (FPGAs)), or systems that contain processors orprogrammable hardware elements, among others. For example, a processingelement may refer to an individual processor in a computer system or thecomputer system itself.

Configurable Elements—Systems or devices that provide configurablefunctionality but do not themselves includes processors that processdata. Configurable elements may produce and/or consume data that may beprovided to or received from various processing elements. A configurableelement may have or receive configuration data that specifiesfunctionality of the configurable element. Configurable elementscomprise data acquisition (DAQ) devices and/or other sensors/devices.

FIG. 2A—Computer System

FIG. 2A illustrates a computer system 82 operable to display and/orexecute a diagram, e.g., a system diagram or graphical program,configured to utilize the various communication techniques disclosedherein. As shown in FIG. 2A, the computer system 82 may include adisplay device operable to display the diagram as the diagram is createdand/or executed. The display device may also be operable to display agraphical user interface or front panel of the graphical program duringexecution of the graphical program. The graphical user interface maycomprise any type of graphical user interface, e.g., depending on thecomputing platform.

The computer system 82 may include a memory medium(s) on which one ormore computer programs or software components according to oneembodiment of the present invention may be stored. For example, thememory medium may store one or more diagrams that are executable toperform the methods described herein. Also, the memory medium may storea development environment application used to create and/or execute suchdiagrams. The memory medium may also store operating system software, aswell as other software for operation of the computer system. Variousembodiments further include receiving or storing instructions and/ordata implemented in accordance with the foregoing description upon acarrier medium.

FIG. 2B—Computer Network

FIG. 2B illustrates a system including a first computer system 82 thatis coupled to a second computer system 90. The computer system 82 may beconnected through a network 84 (or a computer bus) to the secondcomputer system 90. The computer systems 82 and 90 may each be any ofvarious types, as desired. The network 84 can also be any of varioustypes, including a LAN (local area network), WAN (wide area network),the Internet, or an Intranet, among others. The computer systems 82 and90 may execute a diagram (e.g., a graphical program or system diagram)in a distributed fashion. For example, computer 82 may execute a firstportion of the block diagram of a graphical program and computer system90 may execute a second portion of the block diagram of the graphicalprogram. As another example, computer 82 may display the graphical userinterface of a graphical program and computer system 90 may execute theblock diagram of the graphical program. Similar descriptions apply toother executable diagrams.

In one embodiment, a GUI of a diagram may be displayed on a displaydevice of the computer system 82, and while at least a portion of thediagram executes on device 190 connected to the computer system 82. Thedevice 190 may include a programmable hardware element and/or mayinclude a processor and memory medium which may execute a real timeoperating system. In one embodiment, the diagram may be downloaded andexecuted on the device 190. For example, an application developmentenvironment with which the diagram is associated may provide support fordownloading a diagram for execution on the device in a real time system.

Exemplary Systems

Embodiments of the present invention may be involved with performingtest and/or measurement functions; controlling and/or modelinginstrumentation or industrial automation hardware; modeling andsimulation functions, e.g., modeling or simulating a device or productbeing developed or tested, etc. Exemplary test applications where thegraphical program may be used include hardware-in-the-loop testing andrapid control prototyping, among others.

However, it is noted that the present invention can be used for aplethora of applications and is not limited to the above applications.In other words, applications discussed in the present description areexemplary only, and the present invention may be used in any of varioustypes of systems. Thus, the system and method of the present inventionis operable to be used in any of various types of applications,including the control of other types of devices such as multimediadevices, video devices, audio devices, telephony devices, Internetdevices, etc., as well as general purpose software applications such asword processing, spreadsheets, network control, network monitoring,financial applications, games, etc.

FIG. 3A illustrates an exemplary instrumentation control system 100which may implement embodiments of the invention. The system 100comprises a host computer 82 which connects to one or more instruments.The host computer 82 may comprise a CPU, a display screen, memory, andone or more input devices such as a mouse or keyboard as shown. Thecomputer 82 may operate with the one or more instruments to analyze,measure or control a unit under test (UUT) or process 150.

The one or more instruments may include a GPIB instrument 112 andassociated GPIB interface card 122, a data acquisition board 114 andassociated signal conditioning circuitry 124, a VXI instrument 116, aPXI instrument 118, a video device or camera 132 and associated imageacquisition (or machine vision) card 134, a motion control device 136and associated motion control interface card 138, and/or one or morecomputer based instrument cards 142, among other types of devices. Thecomputer system may couple to and operate with one or more of theseinstruments. The instruments may be coupled to a unit under test (UUT)or process 150, or may be coupled to receive field signals, typicallygenerated by transducers. The system 100 may be used in a dataacquisition and control application, in a test and measurementapplication, an image processing or machine vision application, aprocess control application, a man-machine interface application, asimulation application, or a hardware-in-the-loop validationapplication, among others.

FIG. 3B illustrates an exemplary industrial automation system 160 whichmay implement embodiments of the invention. The industrial automationsystem 160 is similar to the instrumentation or test and measurementsystem 100 shown in FIG. 3A. Elements which are similar or identical toelements in FIG. 3A have the same reference numerals for convenience.The system 160 may comprise a computer 82 which connects to one or moredevices or instruments. The computer 82 may comprise a CPU, a displayscreen, memory, and one or more input devices such as a mouse orkeyboard as shown. The computer 82 may operate with the one or moredevices to a process or device 150 to perform an automation function,such as MMI (Man Machine Interface), SCADA (Supervisory Control and DataAcquisition), portable or distributed data acquisition, process control,advanced analysis, or other control, among others.

The one or more devices may include a data acquisition board 114 andassociated signal conditioning circuitry 124, a PXI instrument 118, avideo device 132 and associated image acquisition card 134, a motioncontrol device 136 and associated motion control interface card 138, afieldbus device 170 and associated fieldbus interface card 172, a PLC(Programmable Logic Controller) 176, a serial instrument 182 andassociated serial interface card 184, or a distributed data acquisitionsystem, such as the Fieldpoint system available from NationalInstruments, among other types of devices.

FIG. 4A is a high-level block diagram of an exemplary system which mayexecute or utilize diagrams. FIG. 4A illustrates a general high-levelblock diagram of a generic control and/or simulation system thatcomprises a controller 92 and a plant 94. The controller 92 represents acontrol system/algorithm the user may be trying to develop. The plant 94represents the system the user may be trying to control. For example, ifthe user is designing an ECU for a car, the controller 92 is the ECU andthe plant 94 is the car's engine (and possibly other components such astransmission, brakes, and so on.) As shown, a user may create a diagramthat specifies or implements the functionality of one or both of thecontroller 92 and the plant 94. For example, a control engineer may usea modeling and simulation tool to create a model (e.g., a graphicalprogram) of the plant 94 and/or to create the algorithm (e.g., agraphical program) for the controller 92.

FIG. 4B illustrates an exemplary system that may perform control and/orsimulation functions. As shown, the controller 92 may be implemented bya computer system 82 or other device (e.g., including a processor andmemory medium and/or including a programmable hardware element) thatexecutes or implements a graphical program. In a similar manner, theplant 94 may be implemented by a computer system or other device 144(e.g., including a processor and memory medium and/or including aprogrammable hardware element) that executes or implements an executablediagram, or may be implemented in or as a real physical system, e.g., acar engine.

In one embodiment of the invention, one or more executable diagrams maybe created which are used in performing rapid control prototyping. RapidControl Prototyping (RCP) generally refers to the process by which auser develops a control algorithm and quickly executes that algorithm ona target controller connected to a real system. The user may develop thecontrol algorithm using a diagram, and the diagram may execute on thecontroller 92, e.g., on a computer system or other device. The computersystem 82 may be a platform that supports real time execution, e.g., adevice including a processor that executes a real time operating system(RTOS), or a device including a programmable hardware element.

In one embodiment of the invention, one or more diagrams may be createdwhich are used in performing Hardware in the Loop (HIL) simulation.Hardware in the Loop (HIL) refers to the execution of the plant model 94in real time to test operation of a real controller 92. For example,once the controller 92 has been designed, it may be expensive andcomplicated to actually test the controller 92 thoroughly in a realplant, e.g., a real car. Thus, the plant model (implemented by agraphical program) is executed in real time to make the real controller92 “believe” or operate as if it is connected to a real plant, e.g., areal engine.

In the embodiments of FIGS. 2A, 2B, and 3B above, one or more of thevarious devices may couple to each other over a network, such as theInternet. In one embodiment, the user operates to select a target devicefrom a plurality of possible target devices for programming orconfiguration using a diagram. Thus the user may create a diagram on acomputer and use (execute) the diagram on that computer or deploy thediagram to a target device (for remote execution on the target device)that is remotely located from the computer and coupled to the computerthrough a network.

Graphical software programs and/or portions of system diagrams whichperform data acquisition, analysis and/or presentation, e.g., formeasurement, instrumentation control, industrial automation, modeling,or simulation, such as in the applications shown in FIGS. 2A and 2B, maybe referred to as virtual instruments.

FIG. 5—Computer System Block Diagram

FIG. 5 is a block diagram representing one embodiment of the computersystem 82 and/or 90 illustrated in FIGS. 1A and 1B, or computer system82 shown in FIG. 2A or 2B. It is noted that any type of computer systemconfiguration or architecture can be used as desired, and FIG. 5illustrates a representative PC embodiment. It is also noted that thecomputer system may be a general-purpose computer system, a computerimplemented on a card installed in a chassis, or other types ofembodiments. Elements of a computer not necessary to understand thepresent description have been omitted for simplicity.

The computer may include at least one central processing unit or CPU(processor) 160 which is coupled to a processor or host bus 162. The CPU160 may be any of various types, including an x86 processor, e.g., aPentium class, a PowerPC processor, a CPU from the SPARC family of RISCprocessors, as well as others. A memory medium, typically comprising RAMand referred to as main memory, 166 is coupled to the host bus 162 bymeans of memory controller 164. The main memory 166 may store diagramsoperable to implement various embodiments of the communicationstechniques disclosed herein. The main memory may also store operatingsystem software, as well as other software for operation of the computersystem.

The host bus 162 may be coupled to an expansion or input/output bus 170by means of a bus controller 168 or bus bridge logic. The expansion bus170 may be the PCI (Peripheral Component Interconnect) expansion bus,although other bus types can be used. The expansion bus 170 includesslots for various devices such as described above. The computer 82further comprises a video display subsystem 180 and hard drive 182coupled to the expansion bus 170. In some embodiments, the computer 82may also include or be coupled to other buses and devices, such as, forexample, GPIB card 122 with GPIB bus 112, an MXI device 186 and VXIchassis 116, etc., as desired.

As shown, a device 190 may also be connected to the computer. The device190 preferably includes a programmable hardware element. The device 190may also or instead comprise a processor and memory that may execute areal time operating system. The computer system may be operable todeploy a diagram to the device 190 for execution of the graphicalprogram on the device 190. The deployed graphical program may take theform of graphical program instructions or data structures that directlyrepresent the diagram.

Alternatively, the deployed diagram may take the form of text code(e.g., C code) generated from the diagram. As another example, thedeployed diagram may take the form of compiled code generated fromeither the diagram or from text code that in turn was generated from thediagram.

FIGS. 6A and 6B—Exemplary Graphical Programs

As described above, a graphical program may include a block diagramportion and a graphical user interface portion. In some embodiments, thegraphical user interface portion may be comprised within the blockdiagram portion. The block diagram portion may include a plurality ofinterconnected nodes or icons which visually indicate functionality ofthe graphical program. Each of the nodes may have one or more inputsand/or outputs for accepting and/or providing data to other nodes in thegraphical program. Each of the nodes in the graphical program mayrepresent software functions or executable code. In other words, thenodes in the graphical program may represent or comprise logicalelements (e.g., virtual instruments (VIs), primitives, etc.)

As also indicated above, the nodes in the graphical program may beinterconnected by lines or wires which indicate that indicate that dataare provided from a first node to a second node in the graphicalprogram. In some embodiments, the wires may be connected to theterminals of nodes in the graphical program. The terminals may provideconnection points for connecting the wires to a node, e.g., toindividual inputs or outputs of the node. Additionally, as describedherein, these wires may be configured (e.g., automatically or manually)to provide data synchronously or asynchronously using various dataexchange semantics and/or data transfer mechanisms (among others). Insome embodiments, wires which indicate transfer of data may be referredto as data transfer wires.

Note that references to configuration of wires (or similar remarks)actually may refer to the user providing input to the graphicalrepresentation of the wire on the display to configure the manner inwhich data is transferred during execution as represented by the wire.For example, configuration of a wire may actually refer to configuringsoftware (code and/or data) represented by the wire (and/or associatedicons). The configured software may then be executable to perform thespecified functionality during diagram execution. In other words, duringexecution data transfer is performed according to the configuration ofthe wire. Additionally, references to the wire providing or conveyingdata between icons in the graphical program may actually mean that datais passed between two software entities executing on the same ordifferent devices according to the placement of and/or configuration ofthe wire. Thus, the wire may indicate (e.g., visually) that data ispassed among nodes in a graphical program during execution. Similarremarks apply to wires and icons in diagrams (e.g., system diagrams)described below. Additionally, further descriptions regardingconfiguration of wires are provided below and in various ones of theprovisionals or patent applications incorporated by reference above.

Note that the wires may also be timing wires which may provide timinginformation (e.g., time stamps) between nodes in the graphical program.Note that in some embodiments, the timing wires may be configurable,e.g., for asynchronous or buffered communication. Such wires may bereferred to as buffered timing wires or asynchronous timing wires. Forfurther information regarding timing wires, please see U.S. applicationSer. No. 10/893,745, titled Graphically Representing Timing in aGraphical Program, which was incorporated by reference above.

In some embodiments, the graphical program may include one or morestructure nodes which indicate control flow among one or more nodes inthe graphical program. For example, the graphical program may include aconditional structure node (e.g., to implement conditional branching, ifstatements, switch statements, signal routing, etc.), a loopingstructure node for implementing looping among one or more nodes (e.g.,while loops, do while loops, for loops, etc.), and/or other control flownodes.

Additionally, the graphical program may visually indicate where portionsof the graphical program are executed. In one embodiment, the visualindication may include a rectangular box that contains a portion ofgraphical code. In some embodiments, this visual indication may bereferred to as a target execution node or icon. The target executionnode may have an interior portion where graphical program code that istargeted for execution on a device is contained. For example, a deviceicon that includes an interior portion that is designed to receivegraphical program code may be referred to as a target execution node.Additionally, or alternatively, this node may be referred to as aexecution target structure node, as described in U.S. Provisional Ser.No. 60/869,221 and incorporated by reference above. As described in thisprovisional application, the target execution node may include (e.g.,may reference) contextual information that allows the graphical programcode to be executed on a target device.

The graphical program may be created or assembled by the user arrangingon a display (e.g., of the computer system 82) a plurality of nodes oricons and then interconnecting the nodes to create the graphicalprogram. In some embodiments, the user may select icons and/or wiresfrom various palettes shown in a development environment on the display.In response to the user assembling the graphical program, datastructures may be created and stored which represent the graphicalprogram. As noted above, the graphical program may comprise a blockdiagram and may also include a user interface portion or front panelportion. Where the graphical program includes a user interface portion,the user may optionally assemble the user interface on the display. Asone example, the user may use the LabVIEW development environment tocreate the graphical program.

In an alternate embodiment, the graphical program may be created by theuser creating or specifying a prototype, followed by automatic creationof the graphical program from the prototype. This functionality isdescribed in U.S. patent application Ser. No. 09/587,682 titled “Systemand Method for Automatically Generating a Graphical Program to Performan Image Processing Algorithm”, which was incorporated by reference inits entirety above. Further descriptions regarding automatic creation ofgraphical programs can be found in U.S. Patent Application PublicationNo. 2001/0020291 which was also incorporated by reference above. Thus,the graphical program may be created in other manners, either manually(by the user) or automatically, as desired. The graphical program mayimplement a measurement function that is desired to be performed by oneor more devices or instruments (e.g., indicated by target executionicons). In other embodiments, the graphical program may implement othertypes of functions, e.g., control, automation, simulation, and so forth,as desired.

FIGS. 6A and 6B illustrate exemplary portions of a graphical programaccording to one embodiment. As shown, the graphical program includes aplurality of interconnected nodes which visually indicates functionalityof the graphical program.

Thus, the plurality of interconnected nodes may visually indicatefunctionality of the graphical program. In other words, during executionof the graphical program, the functionality represented by the pluralityof interconnected nodes may be performed.

FIGS. 7A-7D—Exemplary System Diagrams

As described above, a system diagram may refer to a diagram comprisingone or more device icons and graphical program code, wherein the deviceicons are use to specify and/or visually indicate where differentportions of graphical program code are deployed/executed. A systemdiagram may include icons or nodes that are connected by lines or wires,e.g., device icons connected to other device icons, a first graphicalcode portion connected to a second graphical code portion.

In a system diagram, as described above, a first node or icon mayprovide data on an output and a wire may connect the output of the nodeto an input of a second node. Similar to descriptions above, an icon ornode providing data on an output may refer to a device executing coderepresented by the icon or node resulting in transferal of data tobetween or among the software representing the nodes. Note that theprogram code or functions represented by the icons may be executing onone device or among a plurality of devices. For example, a first devicemay be executing code of the first node and a second device may beexecuting code of the second node, and data may be transferred betweenthe devices as indicated by the nodes and/or wires connecting the nodes.

Thus, the icons (nodes) in the system diagram may represent logicalelements such as, for example, software functions or virtualinstruments. Similar to the graphical programs described above,graphical indications may be displayed on the diagram which visuallyindicate where code represented by the various icons execute. Forexample, target execution icons may visually outline one or more of theicons and indicate that software represented by those icons execute on aspecified target or device.

Additionally, in system diagrams, the icon or node providing data mayalso refer to devices (such as processing elements and configurableelements) transferring data according to configurations of the wireand/or icons. Thus, the icons may represent devices and the wire mayindicate that the devices are configured to operate to provide data asindicated by the wires and/or icons in the system diagram. Thus, thewire may visually indicate that data from the first node is provided tothe second node (e.g., the device(s) executing the first and secondnodes). Similar to above, the wire may be configured using variousmethods described herein.

Thus, as noted above, the system diagram may also include icons whichrepresent various devices, e.g., configurable or processing elements. Insome embodiments, the devices represented in the system (e.g.,processing elements, configurable elements, and/or other devices) may bephysically present in the system or may be virtual (e.g., the devicesmay be simulated during execution of the system diagram) as desired.Additionally, these devices may operate according to the functionalityvisually represented by the icons in the system diagram which representthe devices. Note that the virtual devices of the system diagram mayhave an underlying model which is usable (e.g., executable) to simulatebehavior of a real device corresponding to the virtual device. Forexample, the underlying model may be a graphical program or otherexecutable code. Alternatively, or additionally, the virtual devices mayrepresent devices that are desired and/or required for the system (e.g.,according to user input).

Additionally, as described above regarding graphical programs, one ormore GUIs may be associated with the system diagram (e.g., logical orphysical components of the system diagram) which may be used duringexecution of the system diagram. Thus, the GUI(s) may act as a frontpanel to the system diagram during execution (e.g., for receiving userinput and displaying information regarding various variables, functions,devices, and/or sensors (among others) that execute or operate duringexecution of the system diagram).

Thus, the system diagram may allow for a logical view of a system aswell as indications regarding execution targets of code represented inthe system diagram. Further, in some embodiments, the system diagram mayalso indicate physical layouts of the system (e.g., physicalconnectivity as well as indications regarding execution of the logicalelements of the diagram). In primary embodiments, the system diagram atleast includes interconnected icons representing software (e.g.,graphical program code) and one or more graphical indications (e.g.,target execution icons) which indicate where these logical elementsexecute.

Similar to the descriptions above regarding assembly of a graphicalprogram, system diagrams may be assembled manually (e.g., where the userselects icons and connects the icons using wires) or automatically(e.g., in response to user input specifying a desired functionality), asdesired. Thus, a system diagram may be assembled manually orautomatically and may include logical elements, processing elements,and/or configurable elements, as desired.

As shown, FIGS. 7A-7D illustrate exemplary system diagrams according toone embodiment. More specifically, FIG. 7A illustrates an exemplarysystem diagram which corresponds to the portions of the graphicalprogram shown in FIGS. 6A and 6B. As shown, FIG. 7A includes a pluralityof interconnected icons which visually indicate functionality of thesystem diagram. Additionally, the system diagram of FIG. 7A includestarget execution icons which indicate where portions of the graphicalprogram are executed.

FIG. 7B illustrates an exemplary system diagram where each targetexecution icon includes a single node inside a loop structure/iterationnode, and where the icons are interconnected by lines. The icon in eachtarget execution icon may represent a plurality of icons which may beinterconnected (e.g., the icon of the execution icon may be a VI orsub-VI). FIG. 7C illustrates an exemplary system diagram where the iconsof the target execution icons are expanded, and FIG. 7D illustrates anexemplary system diagram where a further sub-VI is expanded. Morespecifically, FIGS. 7B-7D illustrate a system diagram where a firstdevice (NI PXI-6255) stores a first portion of a graphical program whichis executable to communicate with a second device (NI PXI-8176). In thiscase, the second device then provides data (during execution) back tothe first device. Thus, FIGS. 7B-7D show both physical and logicalrelationships among graphical program portions executing on two devices.Thus, FIGS. 7A-7D illustrate exemplary system diagrams.

Exemplary Physical Diagram

As described above, a physical diagram may refer to a diagram whichindicates physical connectivity between physical devices in a system.For example, the physical diagram may visually indicate the connectivityof various physical devices in a measurement system, e.g., a computerconnected to a measurement device via an Ethernet network. A physicaldiagram may show how executable functionality (e.g., of a graphicalprogram or system diagram) is implemented in the real world. Thus, inprimary embodiments, the physical diagram includes a plurality ofinterconnected icons, where each icon in the physical diagramcorresponds to a physical device. Additionally, following theseembodiments, connections between the icons in the physical diagramrepresents physical connectivity. For example, the wires between theicons in the physical diagram may represent Ethernet cables, USBconnections, Firewire connections, and/or other physical media whichconnects devices in the system. In some embodiments, physical diagrams(and/or system diagrams) may also be useful for visualizing variable,channel, or network relationships among devices in the system. Note thata certain type of wire may also be used to represent a wirelessconnection.

Note that in some embodiments, configuration diagrams may have a similarappearance and/or use as physical diagrams. However, configurationdiagrams may refer to diagrams which are not linked to physical realityas are physical diagrams. For example, one or more of the devices in aconfiguration diagram may not be physically present in the system (e.g.,it may be simulated or implement on other devices in the system). Thus,physical diagrams represent physical components and physicalconnectivity of a system and configuration diagrams may representphysical components and/or virtual (or desired) components.

An exemplary physical diagram is shown in the bottom portion of FIGS. 8Aand 8B (described in more detail below).

FIGS. 8A and 8B—Synergy of Multiple Diagrams

In some embodiments, it may be desirable to display or use multiplediagrams. For example, graphical programs may allow users to see alogical view of a system. Similarly, system diagrams may provide an easyand intuitive means for visualizing the logical view of a systems aswell as locations of execution and relationships between other physicalor virtual devices of the system. Thus, a system diagram may allow auser to easily understand functionality and logical flow of executionover an entire system. Physical diagrams and/or configuration diagrams,on the other hand, may allow users to view the physical components andconnectivity of the physical components. Thus, each of the variousdiagrams may provide different views of a system.

In some embodiments, it may be desirable to allow a user to choose oneor more of these diagrams or “views” of the system. For example, theuser may want to see a purely logical view of a system. In this example,a graphical program may be displayed for the user, e.g., on the computersystem 82. The graphical program may be displayed with or withoutgraphical indications (e.g., target execution icons) which visuallyindicate where portions of the graphical program are executed.Alternatively, the user may desire a system view of the system whereboth logical elements and execution indications are displayed.Additionally, the system view may include icons representing hardwaredevices (e.g., processing elements or configurable elements) that maynot be present in the graphical programs. Finally, the user may want toview a physical representation of the system; correspondingly, thephysical diagram may be displayed on the display of the computer system82.

In some embodiments, the multiple diagrams or views may each take up theentirety of the display. Thus, the user may, in one embodiment, togglebetween the different views. Alternatively, the diagrams or views may bedisplayed in a “split view” where a plurality of diagrams or views areshown on the display, or the different diagram are shown separately andconcurrently on multiple display devices. For example, in oneembodiment, a split view may be displayed where a system diagram orgraphical program is displayed in a top portion and the physical view(physical diagram) may be displayed on the bottom portion. In anotherexample, in one embodiment, a split view may be displayed where a systemdiagram or graphical program is displayed on a first display device andthe physical view (physical diagram) may be displayed on a seconddisplay device. This may be especially useful for conveying overallsystem information to the user. Thus, in one embodiment, the user maysee a logical view of the system which may or may not indicate wherelogical elements execute as well as a physical view of the systemallowing intuitive understanding of the entire system in one view.

In some embodiments, the development environment may allow the user tosee correlations between the logical view and the physical view. Forexample, following the split view embodiment from above, a user may beable to select a physical component in the physical view andcorresponding graphical indications in the logical view may be visuallymodified to indicate where graphical program portions execute. Forexample, the user may select a computer system in the physical view andone or more target execution icons (or possibly icons comprised in thetarget execution icons themselves) may “pop” (e.g., appear to jump orbounce on the screen), change colors, become highlighted, marching ants,and/or otherwise be visually indicated. Similarly, the user may selectvarious components in the logical view and corresponding hardwaredevices in the physical view may be highlighted or visually indicated.Thus, the user may easily discern which logical elements in the systemdiagram or graphical program correspond to the physical devices shown inthe physical diagram.

As shown, FIGS. 8A and 8B illustrate exemplary split views of a systemdiagram and a physical diagram. Note that these Figures correspond tothe system diagrams illustrated in FIGS. 7B-7D. As shown in 8A, the topportion illustrates the system diagram of FIG. 7B and the bottom portionshows the physical connectivity between the two devices of the system(in this case from a port of a chassis to a computer). Morespecifically, FIG. 8A depicts a data streaming application where data isread from the PXI-6255, streamed over DMA to the PXI-8176, which aftermodifying the data, streams data back to the PXI-6255 to be output. TheFIFO affordance of the wire is used as an access point for configuringbuffering policies for the configurable wire. This Figure alsoillustrates the concept that a single physical device (in this case thePXI-6255) can have multiple logical representations

Similarly, FIG. 8B shows the same split view with an expanded systemdiagram (from FIG. 7C). Thus, FIGS. 8A and 8B show exemplary split viewsof a system diagram and physical diagram.

Note that the above described views are exemplary only and that otherviews are contemplated. For example, in some embodiments, there may be asingle view, e.g., of a system diagram, where all physical and logicalconnectivity is indicated. Thus, in these embodiments, the user mayeasily understand the entirety of the system. FIGS. 9A and 9B illustrateexemplary diagrams of this case. As shown in FIG. 9A, the cRIO-9014Microprocessor is connected to cRIO-9103 which is connected to 9211. Inthis case, instead of separating the logical components of the cRIO-9014and cRIO-9103 separate target execution icons, the physical and logicalrelationship is shown in a single view. Similarly, FIG. 9B shows thissingle view, but also shows the logic of the cRIO-9014. Note that invarious embodiments, the user may switch between any of theviews/diagrams described above, as desired.

Alternatively, or additionally, more than two diagrams may be shownsimultaneously. For example, two or more of a physical diagram, aconfiguration diagram, a system diagram, and/or a graphical program(among other diagrams) may be displayed at the same time. In someembodiments, various ones of the diagrams may be overlaid in anintelligent manner, to convey an intuitive understanding of the systemto the user. For example, when two or more diagrams are overlaid,corresponding nodes or icons in the different diagrams may be shown inthe same position on the display to indicate correspondence. In oneembodiment, a diagram may be automatically modified to allow thiscorrespondence to be readily displayed. Thus, the above described viewsare exemplary other, and other views are envisioned.

In one embodiment, one or more of the above described diagrams may beused for mapping system configurations to existing systemconfigurations. For example, in one embodiment, the user may wish to mapa diagram (e.g., containing specified physical and logical elements) toan existing (physical) system. For example, the existing diagram mayhave physical components (e.g., devices) which differ from the user'sexisting (physical) system. The development environment may be able tomap the diagram (e.g., automatically) to the existing system and/orsimulate the missing devices that are indicated in the diagram. Thus,diagrams may be mapped onto real systems by transferring functionalityto existing systems or via simulation of the missing components (amongothers).

Thus, FIGS. 6-9 illustrate exemplary diagrams/views of systems. Thefollowing sections describe configuration and display of data transferfunctionality in the various diagrams described above (among others).

FIG. 10—Method for Configuring Wires in a Diagram

FIG. 10 illustrates a computer-implemented method for configuring wiresin a diagram according to one embodiment. The method shown in FIG. 10may be used in conjunction with any of the computer systems or devicesshown in the above Figures, among other devices. In various embodiments,some of the method elements shown may be performed concurrently,performed in a different order than shown, or omitted. Additional methodelements may also be performed as desired. As shown, this method mayoperate as follows.

In 1002, a diagram may be displayed on a display (e.g., of the computersystem 82) in response to user input. The diagram may include aplurality of icons or nodes that are connected by wires. Theseinterconnected nodes or icons may visually represent functionality ofthe diagram, e.g., functionality that may be performed during executionof the diagram. Thus, the diagram may be an executable diagram that isexecutable to perform the functionality indicated by the diagram. Invarious embodiments, the diagram may be a system diagram, graphicalprogram, and/or other type of executable diagram. As described aboveregarding system diagrams and graphical programs, the diagram may becreated or assembled manually or automatically as desired. As alsodescribed above, elements in the diagram may include logical elements,processing elements, and/or configurable elements, among others. Inprimary embodiments, the diagram at least includes a plurality of iconsrepresenting software functions or code that are connected by wires,e.g., data transfer wires and/or timing wires. In other words, thediagram at least includes some graphical program code. Additionally, thediagram preferably includes target execution icons which indicate thatone or more graphical program nodes are executed on respective devicesof the system. Note that the diagram may include icons representingvarious devices (physical or virtual). In some embodiments, the devicesmay provide or accept data from each other and/or software functionsthat are represented by icons in the diagram as configured by the user.

Displaying the diagram in 1002 may include displaying a first wire thatconnects a first icon and a second icon in the diagram. Displaying thefirst wire may include receiving user input connecting the two icons,e.g., using a wiring tool or a selected wire from a palette (among othermethods). In some embodiments, as indicated above, the icons may includeor have associated terminals for connecting wires. For example, thefirst (and/or second) icon may have one or more inputs and one or moreoutputs with terminals for each respective input or output. The inputsand outputs may represent inputs or outputs of the software or code thatis represented by the icon. Thus, receiving user input connecting thetwo icons may include connecting a first wire from a first terminal(e.g., on the first icon) to a second terminal (e.g., on the secondicon). Note that in some embodiments, the first icon (e.g., an output ofthe first icon) may be connected to multiple other icons (e.g., to theinputs of multiple other icons). Thus, the wire may branch and connectthe first icon to a plurality of icons. Note that in some embodiments,the wire may be connected to a plurality of outputs of icons, aplurality of inputs of other icons, or any combination thereof. Thus,the wire may provide connections in a one-to-one, many-to-one, orone-to-many relationship among icons in the diagram, as desired. Invarious embodiments, the entirety or individual branches of the wire maybe configured using the methods described herein (among others).

In some embodiments, the first icon (node) may represent code orsoftware that is targeted for execution on a first device and the secondicon (node) may represent code that is targeted for execution on asecond device. However, note that wires may be configured even when thetwo icons represent different portions of code that are executed by thesame device. Alternatively, the first icon may represent devices such asprocessing elements or configurable elements (among others). In theseembodiments, the devices may operate or execute to provide dataaccording to configurations of the icons or wires connecting the icons.In one embodiment, the first icon may be a primitive, a VI or sub-VI, anI/O icon, and/or a Harness icon. Note that harness icons may refer toicons which surround or otherwise provide data transfer conversion foran icon in the diagram (or possibly a plurality of icons). Harness iconsmay provide similar functionality as the data transfer icons describedbelow, but may provide or specify data transfer functionality for one ormore (or all) of the inputs and outputs of the icon(s) which the harnessicon surrounds. Thus, the first icon may be any of numerous typesappropriate for the diagram.

In primary embodiments, the first wire is a data transfer wire whichindicates that data are transferred from the first icon to the secondicon (e.g., from a first software process to a second software process,or from a first device executing the first icon to a second deviceexecuting the second icon). Note that in various embodiments, the firstwire may also indicate transferal of other information such as datatransport status information and/or constant information (indicatingwhether or not the data being passed is a constant). Furthermore, thefirst wire may also indicate conveyance of timing information such astime stamps, e.g., with corresponding data packets. Thus, the first wiremay indicate that data and possibly other information is passed betweenthe icons (e.g., the devices executing the icons).

In 1004, the first wire may be configured, e.g., in response to userinput. Configuring the first wire may specify data transferfunctionality of the first wire. In some embodiments, the data transferfunctionality may include asynchronous data transfer functionality. Asused herein, data transfer functionality refers to the method by whichdata are transferred in the system (e.g., within a device, or amongdevices), as represented by wires and/or icons in the diagram. Forexample, where the icons represent devices in the system, the term “datatransfer functionality” may refer to the data transfer methods used bythe devices to transfer data between themselves. Where the iconscorrespond to software programs (or software functions), the term “datatransfer functionality” may refer to the data transfer methods used bythe respective software programs transferring data between each other(e.g., the data transfer methods used by the respective devicesexecuting the software programs).

Furthermore, descriptions regarding the wire transferring data betweenicons, icons providing or receiving data, and/or execution of icons(among other similar remarks) may refer to the operation of devicesrepresented by the devices or execution of software programs which maybe executed by one or more devices. For example, as noted above, a firsticon transferring data to a second icon may actually refer to executionof respective software code represented by the first and second iconwhich, during execution, results in data transferal according toconfigurations of the first icon, the second icon, and/or the wirebetween the icons (among other associated elements or icons).

In some embodiments, the code represented by the first icon and thesecond icon may be executed on a single device or multiple devices.Where the code is executed on a single device, the first icontransferring data to the second icon may refer to first software code(represented by the first icon) transferring data to second softwarecode (represented by the second icon) according to the data transferfunctionality specified for the corresponding wires and/or icons. Wherethe code is executed over multiple devices, the first icon transferringdata to the second icon may refer to a first device (executing coderepresented by the first icon) transferring data to a second device(executing code represented by the second icon) according to the datatransfer functionality specified for the corresponding wires and/oricons. Alternatively, the icons may represent devices in the system, andcorrespondingly, data being provided from a first icon to a second iconmay refer to data transferal from the device represented by the firsticon to another device represented by the second icon. Thus, icons maynot actually perform transferal, provision, or consumption of data, butmay be configured or indicate that software or devices areoperable/executable to perform these acts.

For example, data transfer functionality may include data exchangesemantics which define communication policies for transferring databetween icons. Data exchange semantics for wires may include readpolicies, write policies, directionality of the wire, associated datastructures (relating to data transfer), wire branching semantics,queues, and/or buffers, among others. In specific embodiments,specifying data exchange semantics may include specifying a FIFO,mailbox, buffer (e.g., a circular buffer), table, and/or other dataexchange semantics.

A mailbox may include a register or shared memory. In some embodiments,the mailbox may store data (e.g., for access by the first icon oranother icon), an indication whether that data value has changed, and/orwhether or not the stream on the wire is open or closed. Additionally, atable may represent a non-degenerate form of a mailbox. The table maystore data, a count parameter, indices (e.g., an index), an indicationas to whether the data has changed, an error value, and/or a streamstate (e.g., whether or not the stream on the wire is open or closed). AFIFO may similarly store data, count control, timeout control, actioncontrol, action result, a stream state, and/or a percent storage value.The action control may include peek (e.g., for returning a count of dataitems without removing the data), read (e.g., for returning count datatimes and removing the data), write (e.g., for writing count dataitems), flush (e.g., for emptying the stream), idle (to disable the nodeor wire), and/or test (e.g., for testing whether a read and/or write iscurrently possible). A circular buffer may similarly store data, count,move read pointer, move write pointer, current read pointer, currentwrite pointer, error, stream state (e.g., open or closed), and/or otherinformation. Additionally, in some embodiments, data exchange semanticsmay include a group, such that FIFOs and/or circular buffers may begrouped in a similar fashion as tables group mailboxes. Thus, in oneembodiment, a table may not be included in the data exchange semantics,and instead groups of FIFOs, circular buffers, and/or mailboxes (amongothers) may be formed or specified.

As described above, data exchange semantics may include read and writepolicies or behavior. These policies may be applicable for a wire, icon,and/or device in the diagram and/or a portion or whole of the diagramitself. For example, policies may include ‘always read new data’, ‘readand erase data’, ‘read and do not erase data’, ‘overwrite data’, and/or‘never overwrite unread data’, among other policies. Thus, reads andwrites may be destructive (where data are removed or overwritten) ornondestructive, as desired. Note that these polices and/ordestructive/nondestructive parameters may be fully configurable by theuser or may be associated with the specific available semantics.

In some embodiments, specification of buffers for the wire may includeconfiguring the size of the buffer, the type of the buffer, initialvalues of the buffer, and/or location of the buffer (e.g., on a singledevice or over multiple devices). Thus, specification of the datatransfer functionality may include specification of the data exchangesemantics described above (and/or parameters associated therewith, suchas count information or timeout parameters).

Data transfer functionality may also include a data transport protocolfor the wire. Thus, specification of the data transfer functionality forthe wire may include specification of a data transport protocol for thewire. Data transport protocols may refer to the specific method used forimplementing data exchange semantics. Data transport protocols mayinclude TCP/IP (transmission control protocol/internet protocol), USB(universal serial bus), DMA (direct memory access), and/or registeraccess. Note that these protocols are exemplary only and that numerousother protocols are envisioned.

In some embodiments, specifying a data transport protocol for the wiremay include adapting the data transport protocol to the data exchangesemantics. Adapting the data transport protocol may combine programlogic with the data transport protocol to implement the data exchangesemantic. For example, it may be possible to configure a DMA channel tobehave as a mailbox or circular buffer, but this may require additionalprogram logic at both ends of the data exchange to create the desiredbehavior using the somewhat rigid protocol in between.

Finally, data transfer functionality may also include a data transportmedium for the first wire. Data transport mediums may refer to thephysical medium over which the data transport protocol is implemented(and correspondingly specified data exchange semantics). Thus,configuring the first wire in the diagram may involve specification ofdata exchange semantics, a data transport protocol, and/or a datatransport medium.

As a specific example, a diagram may have a first icon and a second iconeach representing different functions. The first icon may representsoftware (e.g., a function or VI) that is targeted for execution on acomputer (e.g., as indicated by a first target execution icon). Thesecond icon may represent software that is targeted for execution on anFPGA (e.g., as indicated by a second target execution icon). Thus,wiring the first and second icon indicates that data are passed betweenthe computer and the FPGA (and in particular, the specific functions orprogram code represented by the first icon and the second icon). The twodevices may be physically connected via a PCI bus. To configure thefirst wire, data exchange semantics may be specified for the first wire.The data exchange semantics may specify that the two devices communicatedata between the software represented by the first icon and the secondicon using a FIFO. However, in order to achieve the specified dataexchange semantics, a data transport mechanism may be specified. Thedata transport mechanism may include the data transport protocol as wellas the physical data transport medium. Thus, configuring the first wiremay include specifying that the two devices communicate over a specificphysical medium, in this case, a PCI bus. The data transport protocolmay therefore be specified using the constraints of the data transportmedium and/or the specified data exchange semantics. In this case, thedata transport protocol may be specified (e.g., automatically) as DMA(direct memory access). Thus, in order to configure wires, data exchangesemantics, data transport protocols, and/or data transport mediums maybe specified.

In some embodiments, the data transfer functionality may be specified bythe user. For example, one or more of the data exchange semantics, datatransport protocol, and/or data transport medium may be specified by auser. In one embodiment, the user may be able to select the first wire,the first icon, the second icon, terminals of the icons, and/or otherassociated icons, such as a harness icon, and invoke a configurationmenu (e.g., a configuration GUI). Furthermore, a series of GUIs or awizard may be used for configuring the first wire. In some embodiments,selecting the first wire, icons, or terminals may include selectingaffordances of the first wire, icons, and/or terminals. For example, insome embodiments, the first wire's affordance may be an icon displayedproximate to the wire and between the endpoints of the wire.Alternatively, the first wire's affordance may be the entirety of thefirst wire. Similar remarks apply to affordances of the icons and theterminals of the icons. As used herein, the term “proximate” is intendedto indicate an association between the two objects, which, in this case,is the icon and the first wire. In some embodiments, proximate may meanwithin one or more centimeters or an inch. Alternatively, proximate maymean within a given number of pixels on the display, e.g., 50 or 100pixels.

The user may then specify one or more of the data exchange semantics,transport protocols, and/or transport mediums via the GUI.Alternatively, or additionally, the data exchange semantics, datatransport protocol, and/or data transport medium may be specified bygeneration of a graphical program. Thus, in some embodiments, agraphical program may be created for the wire in order to specify all ora portion of the data transfer functionality. Similar to descriptionsabove, the graphical program may be created manually or automatically asdesired.

Alternatively, or additionally, the user may specify default values(e.g., globally or with respect to individual icons, target devices,and/or wires in the diagram). Thus, in some embodiments, the first wiremay be specified according to default exchange semantics, transportprotocols, and/or transport mediums (among others) until furtherconfigured is performed (if desired).

Note, however, that one or more of the data exchange semantics, datatransport protocol, and/or data transport medium may be specifiedautomatically, e.g., by the development environment or other processes.Automatically configuring the wire may include automatically determiningthe data exchange semantics, data transport protocol, and/or datatransport medium without receiving user input specifying the specificrespective exchange semantics, transport protocol, and/or transportmedium. Automatic configuration of the first wire may be performed basedon communication or configuration policies of the connected icons (e.g.,of the first and/or the second icons which the fire wire connects),communication policies of the diagram (e.g., global communicationpolicies), default values, and/or other factors.

However, it should be noted that, in some embodiments, automaticspecification of some or all of the data transfer functionality of thewire may not use default values; in other words, in some embodiments,automatic determination and/or specification of data transferfunctionality of the wire may be performed intelligently on a case bycase basis. In some embodiments, the entirety of the data transferfunctionality may be specified and/or determined automatically or aportion may be determined automatically. However, as indicated above,some or all of the data transfer functionality may be specified manuallyby the user. Thus, any combination of manual and automatic configurationmay be used for the data transfer functionality or portions thereof.

For example, in one embodiment, the user may manually specify dataexchange semantics for the wire, e.g., using a GUI, and the datatransport protocol and/or the data transport medium may be determinedautomatically. In one embodiment, the data transport medium may beselected automatically based on the possible connectivities between thetwo devices executing the respective code represented by the first andsecond icons. In some systems, this may be easily determined, e.g.,where the two devices are only connected via one medium or pathway.However, in more complex systems, devices may be coupled via a pluralityof paths. Correspondingly, in such embodiments, automaticallydetermining the data transport medium may be performed based on thespecified data exchange semantics (e.g., determining which datatransport medium would most effectively allow the specified dataexchange semantics), path length, path cost, power requirements of thepath, default pathways (e.g., specified by the user), and/or otherconsiderations. Additionally, selection of the data transport medium maydepend on the determination or specification of the data transportprotocol and/or data exchange semantics.

Similarly, the data transport protocol may be automatically determinedbased on specified data exchange semantics and/or data transport medium.Because data transport protocols have some dependency on the physicalmedium through which the protocol is transmitted, automaticallydetermining the protocol may be based on available connections betweenthe two devices (e.g., the data transport medium). Additionally, somedata exchange semantics may be only implemented using a subset of theavailable data transport protocols. Thus, automatically determining thedata transport protocol may be determined by eliminating options whichdo not conform to already specified exchange semantics and/or transportmediums (or disallowed protocols specified for the wire/diagram), amongothers.

Finally, data exchange semantics may be similarly determined. Morespecifically, the data exchange may be automatically determinedaccording to already specified data transport mediums and/or protocols,diagram communication policies, icon communication policies, devicecommunication policies, and/or other considerations. In one embodiment,the data exchange semantics may be automatically determined based on theicons connected by the first wire. For example, the first icon mayprovide data at a certain periodic rate while the second icon consumesdata at a second rate. Correspondingly, a data exchange semantic may beautomatically determined so that data are provided from the first iconto the second icon where data are not lost and are always available forconsumption. Note that other embodiments are envisioned.

Additionally, automatically determining one or more of the data exchangesemantics, data transport protocol, and/or data transport medium mayinvolve (automatic) analysis of the graphical program code (e.g., in thegraphical program and/or system diagram). For example, an analysis ofthe graphical program code (which includes the first icon) may revealhow data should be provided (and/or for what purpose). Similarly, ananalysis of the graphical program code which includes the second icon(e.g., whose code may be executing on a separate device) may reveal howdata will be consumed. Correspondingly, this analysis may be used todetermine optimal data exchange semantics, data transport protocol,and/or data transport medium, e.g., automatically.

Note that, as indicated above, any of the data exchange semantics, datatransport protocol, or data transport medium may be determinedautomatically or manually. In other words, none, a portion, or theentirety of the data transfer functionality may be determinedautomatically. Thus, the data transfer functionality may be determinedautomatically and/or manually, as desired.

In 1006, the diagram may be executed. During execution of the diagram,data may be provided from the first icon to the second icon according tothe data transfer functionality. Thus, in embodiments where coderepresented by the two icons is executing on different devices (e.g., asindicated by target execution icons), the data may be provided accordingto the data exchange semantic using the data transport protocol via thedata transport medium. Thus, FIG. 10 illustrates an exemplary method forconfiguring a wire in an executable diagram.

FIG. 11—Method for Automatically Determining a Data Transport Protocol

FIG. 11 illustrates a computer-implemented method for configuring wiresin a diagram according to one embodiment. The method shown in FIG. 11may be used in conjunction with any of the computer systems or devicesshown in the above Figures, among other devices. In various embodiments,some of the method elements shown may be performed concurrently,performed in a different order than shown, or omitted. Additional methodelements may also be performed as desired. As shown, this method mayoperate as follows.

In 1102, a diagram may be displayed according to the embodimentsdescribed above in 1002, among others.

In 1104, data exchange semantics may be specified for the first wire. Asdescribed above, the data exchange semantics may indicate or specify howdata are transferred between the first icon and the second icon. Dataexchange semantics may include read policies, write policies,directionality of the wire (e.g., one way or two way directionality),associated or included data structures relating to data transferfunctionality, wire branching semantics, queues, buffers, etc.

Similar to descriptions above in FIG. 10, the data exchange semanticsmay be specified by a user. As indicated above, the user may select thefirst wire and select or specify the data exchange semantics using avariety of methods (e.g., by clicking or selecting affordancesassociated with the wire, the first icon, the second icon, and/orterminals associated therewith). In some embodiments, the user mayselect the data exchange semantics by using a GUI or a series of GUIs(e.g., a wizard). Additionally, as also described above, the dataexchange semantics may be specified automatically based on endpoints ofthe wires, global policies, device policies, icon policies, and/or otherfactors. Alternatively, or additionally, specifying the data exchangesemantics may include specifying or assembling a graphical program forthe first wire. As indicated above, the graphical program may beassembled or specified automatically or manually as desired. Thus, dataexchange semantics may be specified for the first wire.

In 1106, a data transport protocol may be automatically determined basedon the specified data exchange semantic. As described above, the datatransport protocol may refer to a method for implementing the dataexchange semantic for the first wire, e.g., using DMA, USB, registeraccess, and/or TCP/IP (among others). Automatically determining the datatransport protocol may be based on the available data transport mediums,the specified data exchange semantics, default values (e.g., of thediagram, icons, and/or devices executing software represented by theicons, among others), operational parameters and/or characteristics ofthe device(s) corresponding to the first and second icons, communicationpolicies (global or local), and/or other information. However, as notedabove, in some embodiments, automatically determining the data transportprotocol may not use default values and instead may intelligentlydetermine the data transport protocol, e.g., based on specificconfigurations/specifications of the icons and/or devices. Additionally,as indicated above, automatically determining the data transportprotocol means that the user does not manually specify the datatransport protocol for the first wire. Thus, in some embodiments, thedata transport protocol may be automatically determined based on atleast the manually specified data exchange semantics. Similarly, thedata transport medium may be specified manually or automatically basedon a number of different factors (as described above). Note that intrivial cases where there is only one data transport medium between thetwo devices no determination of the data transport medium may benecessary.

In 1108, the first wire may be configured according to the data exchangesemantics, the data transport protocol, and/or the data transportmedium. As indicated above, configuring the wire may include adaptingthe data transport protocol to the data exchange semantic. Adapting thedata transport protocol may involve combining program logic with thedata transport protocol to implement the data exchange semantic.

Thus, after configuration, the diagram may be executable to perform thedata transfer functionality between the first and second icons asindicated and/or specified by the wire. Thus, the user may specify dataexchange semantics for the first wire and a data transport protocoland/or data transport medium may be automatically determined based onthe specified data exchange semantics (and/or other information).Correspondingly, the diagram may execute according to the specified datatransfer functionality.

FIG. 12—Diagram Wires which Visually Indicate Data TransferFunctionality

FIG. 12 illustrates a computer-implemented method for configuring wireswhich visually indicate data transfer functionality according to oneembodiment. The method shown in FIG. 12 may be used in conjunction withany of the computer systems or devices shown in the above Figures, amongother devices. In various embodiments, some of the method elements shownmay be performed concurrently, performed in a different order thanshown, or omitted. Additional method elements may also be performed asdesired. As shown, this method may operate as follows.

In 1202, a diagram may be displayed according to the embodimentsdescribed above in 1002, among others.

In 1204, data transfer functionality may be specified for the firstwire. As described above, the data transfer functionality may includedata exchange semantics, a data transport protocol, and/or a datatransport medium. Additionally, as also indicated above, the datatransfer functionality may be determined and specified automatically ormanually (in part or in whole) as desired. Thus, the wire may beconfigured to perform the data transfer functionality during execution.

In 1206, the first wire may visually indicate that data from the firsticon is provided to the second icon according the specified datatransfer functionality. The first wire visually indicating the datatransfer functionality (e.g., the data exchange semantics, the datatransport protocol, and/or the data transport medium) may be performedin response to configuration of the wire. However, in some embodiments,the first wire indicating the data transfer functionality may be limitedto visually indicating the data exchange semantics and/or the datatransport protocol. In other words, in some embodiments, the first wiremay only indicate the configurable aspects of the data transferfunctionality and may not simply indicate the type of physicalconnection between the two icons (e.g., the connection between thedevices executing code represented by the icons).

In some embodiments, the method may include storing a plurality ofpossible visual appearances, e.g., for the first wire or any wire in thediagram. Correspondingly, the first wire visually indicating the datatransfer functionality may include displaying one of the plurality ofpossible visual appearances based on the specified data transferfunctionality (e.g., the data exchange semantics). In variousembodiments, the plurality of possible visual appearances (and/or thevisual appearance of the first wire) may vary according to differentpatterns, different colors, and/or different thicknesses (among others).For example, in some embodiments, a wire with buffered data exchangesemantics may have a specific color, pattern, and/or thickness which maybe associated with the specified (or generic) buffered data exchangesemantics. Similarly, other specified aspects of the data transferfunctionality may have corresponding associated appearances or aspects.In some embodiments, patterns may be associated with data exchangesemantics and color may be associated with data transport protocols.Note that these associations are exemplary only and that anycharacteristic of the appearance may be associated with anycharacteristic of the data transfer functionality. Alternatively, thewhole appearance may vary according to the entirety of the specifieddata transfer functionality.

In some embodiments, the appearance of the first wire may vary in otherways (e.g., in addition to the pattern, size, and thickness of thewire). For example, in various embodiments, the wire may take on a threedimensional (3-d or 3D) appearance, a tube appearance, a separatedappearance (e.g., where the wire may not be displayed continuously onthe display), a curved appearance, rectangular appearance, and/or otherappearances. Thus, the wire may have any of a variety of appearancesbased on the specified data transfer functionality.

As indicated above, in some embodiments, an icon may be associated withthe wire (e.g., displayed proximate or on the wire) which visuallyindicates the specified data transfer functionality. The icon may be inaddition to or as an alternative to the visual appearance of the wireitself. In various embodiments, the icon may be a data transfer icon ora data transfer indicator (both described in more detail below).

In some embodiments, the icon may represent a mailbox, indicatingmailbox data exchange semantics. The icon may take on the appearance ofa mailbox, or in simpler embodiments, may be an icon which includes anarrow and a rectangle. Alternatively, the icon may represent a circularbuffer (as specified in the data exchange semantics for the wire). Inthis case, the icon may include at least one circle and an arrow. In oneembodiment, the icon may represent a FIFO (first in first out), and theicon may include a plurality of rectangles (e.g., forming a largerrectangle) and an arrow. Note that the above described icon is exemplaryonly and other icons are envisioned which are associated with variousones of the data exchange semantics, data transport protocol, and/ordata transport medium, as desired.

Note that the wire visually indicating the data transfer functionality(or more specifically the data exchange semantics) may include replacinga generic or default appearance with a new appearance. Thus, in someembodiments, the wire may have a first appearance, e.g., when firstdisplayed in the diagram, and may take on a new appearance afterconfiguration. Alternatively, or additionally, the wire may have a firstappearance during wiring (e.g., while the wire is being connectedbetween the two icons) and may take on a configured appearance aftercompletion of the connect (e.g., where at least a part of the datatransfer functionality is automatically determined upon connection).

In some embodiments, instead of selecting a generic wire and configuringthe wire, the user may select a wire of a plurality of differentpossible wires. Each of these wires may represent different datatransfer functionalities (e.g., data exchange semantics) and maycorrespondingly visually represent the respective data transferfunctionality. Thus, instead of the user connecting the two icons andconfiguring the wire (resulting in the wire visually indicating thespecified data transfer functionality), the user may select a wire froma plurality of wires that is already configured according to the desireddata transfer functionality. Correspondingly, that wire may visuallyrepresent the desired data transfer functionality.

Thus, in some embodiments, after configuration, the wire may visuallyindicate the data transfer functionality. Correspondingly, duringexecution, data may transferred according to the data transferfunctionality.

FIG. 13—Configuring Data Transfer Functionality Using a Data TransferIcon

FIG. 13 illustrates a computer-implemented method for configuring datatransfer functionality using a data transfer icon according to oneembodiment. The method shown in FIG. 13 may be used in conjunction withany of the computer systems or devices shown in the above Figures, amongother devices. In various embodiments, some of the method elements shownmay be performed concurrently, performed in a different order thanshown, or omitted. Additional method elements may also be performed asdesired. As shown, this method may operate as follows.

In 1302, a diagram may be displayed, e.g., according to the embodimentsdescribed above in 1002, among others.

Displaying the diagram may include displaying a first icon in thediagram. As described above, the first icon may have input(s) and/oroutput(s) associated with the icon. For example, the first icon may haveterminals associated with each respective input or output for connectingwires to the icon. Thus, data may be provided or received on theinputs/outputs of the icon. As also indicated above, the first icon mayrepresent a processing element, software code, and/or a device. Inprimary embodiments, the first icon represents software code that isexecutable by a first device (e.g., a measurement device). In oneembodiment, the first icon may be a primitive, a VI or sub-VI, an I/Oicon, and/or a Harness icon. Thus, the first icon may be any of numeroustypes appropriate for the diagram.

In 1304, a data transfer icon may be selected, e.g., by a user. Forexample, in one embodiment, the user may select the data transfer iconfrom a plurality of icons, e.g., displayed in a palette of thedevelopment environment. More specifically, the palette may include aplurality of icons related to assembling the graphical program and/orthe system diagram.

In 1306, the data transfer icon may be configured. For example,configuring the data transfer icon may include specifying data transferfunctionality for the data transfer icon. In preferred embodiments,specifying the data transfer functionality includes specifying dataexchange semantics for the data transfer icon. However, as describedabove, configuring the data transfer icon may include specification ofdata exchange semantics, a data transport protocol, and/or a datatransport medium. Additionally, as also indicated above, the datatransfer functionality may be determined and specified automatically ormanually (in part or in whole) as desired. For example, configuring thedata transfer icon may include displaying a GUI, e.g., in response touser input. Alternatively, or additionally, configuring the datatransfer icon may include specifying or assembling a graphical programfor the data transfer icon, automatically or manually, as desired. Thus,the data transfer icon may be configured to perform the data transferfunctionality during execution.

In preferred embodiments, similar to remarks above, the data transfericon may visually indicate the specified data transfer functionality.For example, the data transfer icon may include or resemble a mailbox, aFIFO, a table, a register, and/or a buffer, among others. In someembodiments, the data transfer icon may represent a mailbox, indicatingmailbox data exchange semantics. The data transfer icon may take on theappearance of a mailbox, or in simpler embodiments, may be an icon whichincludes an arrow and a rectangle. Alternatively, the data transfer iconmay represent a circular buffer (as specified in the data exchangesemantics for the wire). In this case, the data transfer icon mayinclude at least one circle and an arrow. In one embodiment, the datatransfer icon may represent a FIFO (first in first out), and the datatransfer icon may include a plurality of rectangles (e.g., forming alarger rectangle) and an arrow. Note that the above describedappearances are exemplary only and other appearances are envisionedwhich are associated with various ones of the data exchange semantics,data transport protocol, and/or data transport medium, as desired.

In 1308, the data transfer icon may be associated with the first icon.The data transfer icon in one embodiment is not intended as astand-alone “function node”, but rather is intended to be associatedwith another node or wire in order to configure that other node or wirewith a data transfer configuration. Associating the data transfer iconwith the first icon may associate the data transfer functionalityspecified for the data transfer icon with the first icon. In someembodiments, associating the data transfer icon with the first icon mayinclude connecting the first icon and the data transfer icon, e.g.,using a wire. Alternatively, the data transfer icon may be included inthe first icon. For example, associating may include inserting the datatransfer icon into the first icon (e.g., dragging and dropping the datatransfer icon onto the first icon). Alternatively, associating the datatransfer icon with the first icon may result in generation of a harnessicon which encompasses the first icon. In such embodiments, the datatransfer icon may no longer be displayed in the diagram and the harnessicon may thereby replace the data transfer icon after the association.Thus, associating the first icon with the data transfer icon mayconfigure the first icon with the data transfer functionality of datatransfer icon.

Alternatively, or additionally, the data transfer icon may perform thedata transfer functionality for the first icon and/or the wire connectedto the first icon. For example, the first icon may transfer dataaccording to synchronous data flow semantics, and the data transfer iconmay provide the specified data transfer functionality, e.g., forbuffered communication. Thus, the data transfer icon may convert thesynchronous data flow semantics to the specified data exchange semanticsof the data transfer functionality. Thus, the data transfer icon mayindicate transferal of data according to the specified data transferfunctionality, e.g., during execution of the diagram. Similarly, in someembodiments, the wire may pass data according to a simple consumptionpolicy, and the data transfer icon(s) may handle specified semantics orpolicies, e.g., buffered communication semantics. Thus, in someembodiments, the data transfer icon may indicate or implement thespecified data transfer functionality for the first icon or wireconnected to the first icon.

The method may further include displaying a second icon in the diagram.In various embodiments, similar to descriptions above, the coderepresented by the first icon may be executed on a first device, andcode represented by the second icon may be executed on a second device.However, it should be noted that the code of the two icons may notnecessarily execute on separate devices, and may in fact execute on thesame device. The two icons may be connected to each other, e.g., using awire. Thus, the method may include associating the first icon with thesecond icon, where during execution of the diagram, data are providedfrom the first icon to the second icon according to the data transferfunctionality.

Following descriptions from above, the data transfer icon may beinterposed between the first icon and the second icon. Similarly, asecond data transfer icon may be associated with the second icon. Thus,in some embodiments, the first data transfer icon may implementspecified data transfer functionality for the first icon and the seconddata transfer icon may implement second specified data transferfunctionality for the second icon. Additionally, in one embodiment,associating the data transfer icon with the first icon may automaticallyinclude associating the second data transfer icon with the second icon.Thus, in some embodiments, the user may choose and insert the datatransfer icon in the diagram and the second data transfer icon may alsobe displayed in the diagram. In some embodiments, the first and secondicons may already be coupled, e.g., via a wire. In some embodiments,data transfer icons may be automatically associated with icons when theyare connected.

However, it should be noted that in some embodiments, the second iconmay be executable to interpret or receive data according to thespecified data transfer functionality (e.g., the data exchangesemantics). In such embodiments, a second data transfer icon may not benecessary for the second icon.

In some embodiments, the first icon and/or the data transfer icon may beconnected to a plurality of other icons in the diagram. For example, thefirst icon may be connected to a wire that branches and connects toother icons. In these embodiments, the data transfer icon may specifydata transfer functionality for communication with

Note that the data transfer icon may be reconfigured to performdifferent data transfer functionality. Additionally, or alternatively,the wire connected to the first icon may be configured/reconfigured,e.g., using the methods described above, among others. In suchembodiments, reconfiguring the wire may be independent or dependent onthe data transfer icon(s) that may be connected to the wire. Thus, insome embodiments, configuring or reconfiguring the wire may configure orreconfigure the data transfer icon(s) as desired. Alternatively, thewire configuration may be separate from the data transfer iconconfiguration. In some embodiments, the wire configuration may be linkedwith a first data transfer icon and not linked to another. This linkingfunctionality may be specifiable by the user. However, it should benoted that in embodiments where the data transfer functionality (or dataexchange semantics) are configured independently, conflicts orincompatibilities in the differently specified data transferfunctionalities may arise. These conflicts may be indicated to the user.For example, in some embodiments, the wire connecting the two icons may“break” or otherwise indicate that the wire is no longer functional.

Thus, data transfer functionality may be specified using data transfericons.

FIG. 14—Data Transfer Indicator

FIG. 14 illustrates a computer-implemented method for configuring datatransfer functionality and indicating the functionality using a datatransfer indicator according to one embodiment. The method shown in FIG.14 may be used in conjunction with any of the computer systems ordevices shown in the above Figures, among other devices. In variousembodiments, some of the method elements shown may be performedconcurrently, performed in a different order than shown, or omitted.Additional method elements may also be performed as desired. As shown,this method may operate as follows.

In 1402, a diagram may be displayed, e.g., according to the embodimentsdescribed above in 1302, among others.

In 1404, data transfer functionality may be specified for the first iconand/or a wire connected to the first icon. The data transferfunctionality may be specified via a variety of methods, such as thosedescribed above, among others. For example, the data transferfunctionality may be specified manually or automatically as desired. Thedata transfer functionality may be specified for the wire, the firsticon, a data transfer icon, a harness icon encompassing the first icon,other icons, and/or affordances associated therewith (among others). Insome embodiments, as indicated above, the first icon may be configuredby assembling a graphical program which specifies the data transferfunctionality. Thus, data transfer functionality (e.g., data exchangessemantics and/or a data transport protocol) may be specified for thefirst icon.

In 1406, a data transfer indicator may be displayed in the diagram. Thedata transfer indicator may visually indicate the specified datatransfer functionality (e.g., of the first icon). In some embodiments,the data transfer indicator may be displayed proximate to the first iconand/or the wire connected to the first icon. Similar to descriptionsabove regarding the icon displayed on or next to the wire and/or thedata transfer icon, the data transfer indicator may have an appearancewhich represents the data transfer functionality. For example, the datatransfer indicator may represent a mailbox, indicating mailbox dataexchange semantics. The data transfer indicator may take on theappearance of a mailbox, or in simpler embodiments, may be an icon whichincludes an arrow and a rectangle. Alternatively, the data transferindicator may represent a circular buffer (as specified in the dataexchange semantics for the wire). In this case, the data transferindicator may include at least one circle and an arrow. In oneembodiment, the data transfer indicator may represent a FIFO (first infirst out), and the data transfer indicator may include a plurality ofrectangles (e.g., forming a larger rectangle) and an arrow. Note thatthe above described appearances are exemplary only and other appearancesare envisioned which are associated with various ones of the dataexchange semantics, data transport protocol, and/or data transportmedium, as desired.

FIGS. 15A-15E—Exemplary GUIs for Configuring a Wire

FIGS. 15A-15E are exemplary screen shots of GUIs for configuring a wireor icon coupled to the wire according to one embodiment. In oneembodiment, one or more of these GUIs may be usable according to themethods described above. However, it should be noted that these areexemplary only and that other GUIs, displays, or methods for receivinginput for configuring wires or icons in the diagram are envisioned.

FIG. 15A is a screen shot of an exemplary GUI for configuring a wire (oricon connected to a wire). As shown, the GUI may indicate the terminalor wire being configured (in this case Boolean 10). The GUI may allowthe user to select data valid behavior (e.g., Data Written only whenTrue), wire type (e.g., timing or buffered), or buffer policy (e.g., 1sample deep, no blocking or N samples deep, block if full), amongothers.

FIG. 15B is a screen shot of an exemplary GUI for configuring a wiretype. As shown, the user may select a write behavior (e.g., 1 sampledeep global or N samples deep FIFO). In this case, N samples deep FIFOis selected with a FIFO depth (in samples) of 10.

FIG. 15C is a screen shot of an exemplary GUI for choosing a bufferedwrite policy. As shown in this Figure, allow overwrite of unread data isselected for a register type communication policy (as indicated by thegraphic in the upper right hand corner). The GUI also includes theability to choose “Never overwrite unread data” (with the option toblock until write succeeds), buffer depth, and use enable control.

FIG. 15D is a similar screen shot of a GUI for choosing a buffered writepolicy of a circular buffer. In this case the buffer depth is 2.

FIG. 15E is a similar screen shot of a GUI for choosing a buffered writepolicy of a FIFO. In this case, the buffer depth is 2 and unread data isnot overwritten. Additional, a block is performed until the writesucceeds. Thus, FIGS. 15A-15E are exemplary screen shots of GUIs forconfiguring a wire or icon of a diagram.

FIGS. 16A-16J—Exemplary Icons

FIGS. 16A-16J illustrate exemplary icons which may be used forindicating or configuring configurable wires. For example, these iconsmay be used as data transfer icons, data transfer indicators, accessors,affordances (e.g., of a wire or icon), and/or other uses (such as thosedescribed above, among others). In various embodiments, one or more ofthese icons may be usable according to the methods described above.However, it should be noted that these are exemplary only and that othericons are envisioned.

FIGS. 16A and 16B illustrate exemplary icons indicating a circularbuffer. FIGS. 16C and 16D illustrate exemplary icons indicating amailbox. FIGS. 16E and 16F illustrate exemplary icons indicating a FIFO.FIG. 16G illustrates an exemplary icon indicating that a global variablemay be used by the wire or terminal (or may “back” the wire). Similarly,FIG. 16H illustrates an exemplary icon (resembling a RAM chip)indicating that memory may be used by the wire or terminal (or may“back” the wire).

FIG. 16I illustrates an exemplary icon indicating a hardware element.FIG. 16J illustrates a harness icon around a VI. As described above, theharness icon may convert between asynchronous data and timing wires andsynchronous dataflow for the VI.

FIGS. 17A-17H—Exemplary Wires with Icons

FIGS. 17A-17H illustrate exemplary configured wires with icons which maybe used for indicating or configuring the wires. Note that the iconsshown here are exemplary only and that other icons (such as thosedescribed above, among others) are envisioned. In various embodiments,one or more of the icons shown in these Figures may be displayed or notdisplayed as desired. Additionally, these exemplary wires may be used inconjunction with any of the systems or methods described above.

As shown, FIG. 17A illustrates two add delta icons connected by a wirewith an affordance which visually indicates that the wire is configuredaccording to a mailbox. Additionally, data transfer icons are connectedbetween the add delta icons and the wire. The data transfer icons alsoindicate that the wire and/or add delta icons are configured accordingto mailbox communication policies. Similarly, FIGS. 17B and 17C show thesame icons except the affordance and data transfer icons indicate thatthe wire/terminals are configured according to a circular buffer andFIFO respectively.

FIG. 17D illustrates the add delta icon with a harness icon whichhandles the communication policies for the add delta icon. As shown, inthis configuration, the affordance and the data transfer icon mayvisually indicate a mailbox configuration. However, in this case, theharness icon may not visually indicate this configuration for the leftmost add delta icon.

Similar to FIG. 17D, FIG. 17E shows a VI connected to the add delta iconusing a mailbox. In this case, the VI may not require a data transfericon (or it may not be displayed, in some embodiments). In this case,the VI may already communicate according to the configured mailboxcommunication policies.

FIG. 17F shows an embodiment where only a data transfer icon indicatesthe configuration of the wire/add delta icon, which, in this case, is amailbox.

FIG. 17G shows a hardware icon connected to an add delta icon with aFIFO (indicated by the affordance of the wire and the data transfer iconof the add delta icon.

FIG. 17H shows a similar display, except with a circular buffer.

Thus, FIGS. 17A-17H illustrate exemplary configured wires with iconswhich may be used for indicating or configuring the wires.

Specification of Data Transfer Functionality and Associated Indications

As described herein, various methods may be used to specify datatransfer functionality between two icons in a diagram (e.g., between twodevices executing code represented by the two icons). Similarly, variousmethods of indicating the data transfer functionality are describedherein. Note that embodiments are envisioned where any combination ofthese methods of specification and/or indication of data transferfunctionality are utilized. In other words, the data transferfunctionality may be specified using any of the methods described above(or any combination thereof), and that the specified data transferfunctionality may be indicated using any of the various methods (or anycombination thereof) also described above. Note further that otherembodiments and methods of specifying and/or indicating data transferfunctionality are envisioned.

Exemplary Specific Embodiments Regarding Configuration of AsynchronousWires

The following descriptions and Figures provide specific embodiments ofconfiguration and/or indication of asynchronous wires in a diagram(e.g., a graphical program or system diagram). Note that theseembodiments are not intended to limit the scope of the invention.However, note that any of the details described below may also apply tothe systems and methods already described above.

FIG. 18 illustrates a computer-implemented method for asynchronouscommunication in a graphical program according to one embodiment. Themethod shown in FIG. 18 may be used in conjunction with any of thecomputer systems or devices shown in the above Figures, among otherdevices. In various embodiments, some of the method elements shown maybe performed concurrently, performed in a different order than shown, oromitted. Additional method elements may also be performed as desired. Asshown, this method may operate as follows.

First, in 1802 a first node and a second node may be displayed in agraphical program, where the graphical program includes a plurality ofinterconnected nodes that visually indicate functionality of thegraphical program. Each of the first and second nodes preferably has arespective functionality, and includes a respective terminal. In otherwords, each node may include a terminal for connecting or wiring thenode to another graphical program element, such as another node, forsending and/or receiving data to and/or from the other node.

The graphical program may be created or assembled by the user arrangingon a display a plurality of nodes or icons and then interconnecting thenodes to create the graphical program. In response to the userassembling the graphical program, data structures may be created andstored which represent the graphical program. The nodes may beinterconnected in one or more of a data flow, control flow, or executionflow format. The graphical program may thus comprise a plurality ofinterconnected nodes or icons that visually indicates the functionalityof the program. As noted above, the graphical program may comprise ablock diagram and may also include a user interface portion or frontpanel portion. Where the graphical program includes a user interfaceportion, the user may optionally assemble the user interface on thedisplay. As one example, the user may use the LabVIEW graphicalprogramming development environment to create the graphical program.

In an alternate embodiment, the graphical program may be created by theuser creating or specifying a prototype, followed by automatic orprogrammatic creation of the graphical program from the prototype. Thisfunctionality is described in U.S. patent application Ser. No.09/587,682 titled “System and Method for Automatically Generating aGraphical Program to Perform an Image Processing Algorithm”, which ishereby incorporated by reference in its entirety as though fully andcompletely set forth herein. The graphical program may be created inother manners, either by the user or programmatically, as desired. Thegraphical program may implement a measurement function that is desiredto be performed by one or more instruments. In other embodiments, thegraphical program may implement other types of functions, e.g., control,automation, simulation, and so forth, as desired.

In 1804, an asynchronous wire may be included in the graphical program,where the asynchronous wire connects the first node and the second nodevia their respective terminals. In other words, a first end of theasynchronous wire may be connected to the terminal of the first node,and a second end of the asynchronous wire may be connected to theterminal of the second node. For example, in one embodiment, the nodesmay be specified or intended respectively as source and sink nodes withrespect to communication between the nodes. FIG. 19 is a high-levelillustration of such source and sink nodes, labeled accordingly,connected via an asynchronous wire. However, it should be noted that inother embodiments the asynchronous wire may facilitate two-waycommunication between the nodes, i.e., from the first node to the secondand from the second node to the first.

In 1806, the asynchronous wire may be configured for asynchronouscommunication between the first and second nodes. For example, variousattributes of the asynchronous wire may be configured or set tofacilitate asynchronous communication between the first node and thesecond node. In one embodiment, these attributes may include one or moreof: a data structure type included in or used by the wire, e.g., a firstin first out (FIFO) queue; buffer size for the asynchronous wire; readpolicy, e.g., block reads if the buffer is empty or uninitialized,remove the element upon a read from the buffer (e.g.,destructive/non-destructive reads), read chunk size, etc.; write policy,e.g., block all writes to the buffer if the buffer is full, overwrite ifthe buffer is full or always, write chunk size, etc.; initial value onthe wire; directionality of the asynchronous wire; and semantics of wiresplits, i.e., how branching of the wire may affect communications usingthe wire, among others. Note that the various policies specified for useof the asynchronous wire may accommodate various models of computation(MoC) for the graphical program, including, for example, Kahn ProcessNetworks (PN) and Communicating Sequential Processes (CSP), amongothers.

In some embodiments, the asynchronous wire may have a defaultconfiguration, i.e., one or more of the attributes may be preset withdefault values. Thus, the configuration of the asynchronous wire (atleast with respect to the default valued attributes) may effectivelyoccur when the wire is included in the block diagram of the graphicalprogram. Of course, even were some or all of the attributes to havedefault values, subsequent configuration of the asynchronous wire, e.g.,by the user or by another process, may overwrite these default valueswith new values. In other words, configuring the asynchronous wire mayinclude overwriting at least one of the default values for the one ormore attributes of the asynchronous wire with a respective at least onenew value.

In one embodiment, a user may be able to configure a terminal on a nodeto be “asynchronous”, after which wires connected to this terminal mayhave asynchronous behavior. In other words, connecting a wire to anasynchronous terminal may automatically invoke creation or instantiationof an asynchronous wire, e.g., via conversion of a normal “synchronous”wire to the asynchronous wire, or replacement of the normal wire withthe asynchronous wire. Users may then click on the asynchronous wire andconfigure its run-time behavior, such as the size of the queue and theread/write policies (blocking/non-blocking, destructive/non-destructivereads), as described above. In other words, once a terminal of a node isconfigured to be asynchronous, any wire connected to that terminal mayautomatically be configured as an asynchronous wire.

In one embodiment, the asynchronous wire and/or the terminal(s) may beconfigured via invocation of a graphical user interface (GUI), e.g., oneor more dialogs, menus, property pages, attribute nodes, etc., e.g., bythe user right-clicking on the asynchronous wire or terminal. The usermay then select or input values for various attributes of theasynchronous wire or terminal. Alternatively, or additionally, theasynchronous wire and/or the terminal(s) may be configured via inputfrom another process, such as a graphical program generation program orwizard. For example, in the case of a wizard, the user may provide inputto various panels or dialogs specifying the attributes. Thus, in variousembodiments, configuration information for the asynchronous wire and/orthe node terminals may be provided by a use via a GUI, and/orprogrammatically by another process, e.g., another program.

In 1808, the graphical program may be executed. In preferredembodiments, executing the graphical program includes executing thefirst and second nodes, where the first and second nodes communicateasynchronously during the execution of the first and second nodes.

FIG. 20 illustrates one embodiment of an exemplary graphical programthat includes two separately executable while loops similar to those ofFIG. 1, where a first loop 2002 includes a first node, in this case arandom number generation node 2003, and a second loop 2004 includes asecond node, in this case an add node 2005, similar to the graphicalprogram of FIG. 1. However, as may be seen, in this embodiment, thefirst node (random number node) 2003 is connected to the second node(add node) 2005 via an asynchronous wire 2006. Note that in thisexample, the asynchronous wire is attached only to the terminals of thefirst and second nodes, and does not attach to the loops themselves.Thus, in this example program, while both loops are executing, causingtheir respective included nodes to execute per cycle, the nodes maycommunicate in an asynchronous manner. More specifically, duringexecution, the random number generator node 2003 may operate to sendrandom number over the asynchronous wire 806 to the add node 2005, whichmay add “1” to the received value, and output the resultant value fordisplay (as a double value).

Thus, the asynchronous wire may allow users to create a staticconnection between nodes in a (block diagram of) a graphical program tofacilitate asynchronous communication between the nodes. In someembodiments, this connection may be depicted as a special, asynchronous,wire with a specific graphical appearance. For example, in oneembodiment, the asynchronous wire may have a 3D tube-like appearance,although any other appearance may be used as desired. Examples of such agraphically rendered asynchronous wire are illustrated in FIGS. 7 and 8.In some embodiments, the directionality of the asynchronous wire mayalso be indicated, e.g., via an arrow or multiple arrows, displayed onor near the asynchronous wire.

In one embodiment, asynchronous wires may be evaluated during a typepropagation phase, e.g., at compile time. This wire evaluation may beperformed as a part of the type propagation phase, e.g., in the LabVIEWdevelopment system. In this phase the diagram may be traversed andlogically executed by type (not by value), so that it is possible tocompute the types of all wires and terminals, and thus to type-check thediagram. For example, constant folding may be used to propagate constantvalues from the source of an asynchronous wire to its sink. In thisapproach, as a part of type propagation, the values of constants areevaluated as far as possible on the diagram. This allows the eliminationof dead code, such as unreachable cases in a case statement. This mayallow the end points to share static entities such as block diagramconstants and constant references, such as references to a VI instance.At run-time this may result in a connection between source and sink thatdoes not obey standard (e.g., LabVIEW) data-flow rules.

For example, in the simple example program of FIG. 19, the source andsink are connected through an asynchronous wire that may carry a stringconstant used to access a common, named queue, which is a FIFO datastructure. Note that a significant difference between a traditionalLabVIEW wire and the asynchronous wire connection between the source andsink is that there is no data flow dependency between them in the lattercase, and so the two graphical program nodes can run in parallel, whileexchanging data. In other words, the asynchronous wire is a new type ofwire with different semantics, where, in particular, there is not thenormal data flow dependency between nodes connected with an asynchronouswire, and in fact, nodes connected by such a wire are actually supposedto run in parallel, as opposed to serially when connected with a regularwire. Note that in general, it would be an error to connect two nodeswith both a regular wire and an asynchronous wire. Note further thatasynchronous wires may be allowed to create cycles in a graphicalprogram, e.g., in a LabVIEW graph, since doing so may not introduce adanger of deadlock or undefined behavior at run-time. Additionally, insome embodiments, multiple sources on asynchronous wires may befacilitated. Similarly, in some embodiments, multiple sinks onasynchronous wires may be allowed.

The asynchronous wire may be denoted by a type attribute (and sobehaviorally polymorphic nodes may be possible), namely, a typedef witha special name. In other words, asynchronous wires may have a data type,and so may benefit from the many uses of such typing, as is well knownto those of skill in the programming arts, e.g., polymorphism and typechecking, among others.

It should be noted that while the example uses of asynchronous wiresdescribed herein are within a single program, in other embodiments,asynchronous wires may be used to connect different programs, e.g., toconnect nodes that are comprised in different respective graphicalprograms. Moreover, in some embodiments, the different programs may beeven running on different processors or programmable hardware elements,such as field programmable gate arrays (FPGAs).

In preferred embodiments, the asynchronous wires may each be implementedby a respective graphical program. In other words, the functionality ofan asynchronous wire may be provided by an associated graphical program.More specifically, each asynchronous wire may use, be associated with,or represent, an instance of a graphical program, which, for brevity,may be referred to simply as a graphical program. Thus, multipleasynchronous wires may each utilize or have a respective instance of thesame graphical program. The graphical program for each asynchronous wiremay be configured to implement and enforce the various communicationpolicies of the wire, e.g., read and write policies, as discussed above.Thus, each instance of the graphical program may be configured for theparticular behavior desired for the respective asynchronous wire. Notethat since graphical programs may store and maintain state information,the data transmitted on or by the asynchronous wire may also be includedin or implemented by the graphical program. Note also that the graphicalprogram associated with an asynchronous wire may not generally bevisible to the user, i.e., may be hidden, although of course, means maybe provided for displaying the graphical program of an asynchronous wirefor development purposes.

Since the endpoints of an asynchronous wire may share a common, staticreference to a VI instance it may be possible to implement a widevariety of run-time connections between the endpoints, thus allowingcustom run-time behavior of a node. For example, in various embodiments,some of the possible behaviors of an asynchronous wire may include:implementing queues of various kinds, including FPGA FIFOs and RT (realtime) FIFOs; single element communication (e.g., anonymous globalvariables); synchronization primitives, such as notifiers, semaphores,rendesvous and occurrences; and expressing a connection to and from apart of a diagram that is being executed on a remote target, e.g.,“roping in” of a piece of a diagram so that it can execute on the remotetarget in conjunction with local execution of the remainder of thediagram.

In some embodiments, an asynchronous wire may not be limited topropagating information from terminal sources to terminal sinks. Inother words, in some embodiments, the asynchronous wire (and possiblythe terminals of the connected nodes) may be configured to transmit datain either direction or in both directions. In other words, in someembodiments and configurations, the asynchronous wire may facilitatetwo-way communications between the connected nodes. For example, in oneembodiment, a dual queue may be used to facilitate such two-waycommunications, where one queue is used for a first direction, andanother queue is used for a second direction, although any other datastructures and techniques may be used as desired.

FIG. 21 is an exemplary graphical program utilizing asynchronous wiresthat is slightly more complex than those of FIGS. 19 and 20, whereinvarious aspects of asynchronous wires are demonstrated in a signalprocessing application. As FIG. 21 shows, beginning from the far left ofthe figure, a generate node 2102 is configured to generate 100 samplesof a function or signal, e.g., a sine wave, and communicate these dataover an asynchronous wire 2103 to upsample node 2104, which may operateto upsample the transmitted signal from the generate node 2102 by afactor of 3, as indicated. The upsampled data may then be transmittedover asynchronous wire 905 to finite filter response (FIR) filter node2106, which is configured with a window of 10 samples. This node mayfilter the received signal and transmit the resulting data to downsamplenode 2108, which may operate to downsample the data by a factor of 2,e.g., halving the number of samples in the signal. The resultant signalor data then proceeds to split node 2110 via asynchronous wire 2109,where the signal is propagated along asynchronous wires 2111 and 2121.Note that split node 2110 demonstrates two asynchronous wires 2111 and2121 sharing a common source, specifically, split node 2110, whosefunction is to take an input and provide output on two different wires.As shown, the data on asynchronous wire 2121 is provided to display node2120 for display, which, as indicated, is configured to display 150samples at a time, e.g., on a graphical user interface (GUI). Thesinusoidal waveform display 2210 of FIG. 22 illustrates exemplary outputfrom the display node 920.

As FIG. 21 indicates, asynchronous wire 2111 may transmit the signal tomerge node 2112 which may operate to interleave data received fromasynchronous wires 2111 and 2119, where, as shown, the signal onasynchronous wire 2119 is from delay node 2118, described below. Theresults of the merge node 2112 may be transmitted on asynchronous wire2113 to split node 2114, which, as shown, may provide the receivedsignal to display node 2122 via asynchronous wire 2123, where the signalmay be displayed 300 samples at a time. The sinusoidal waveform display2220 of FIG. 22 illustrates exemplary output from the display node 2122.

The split node 2114 may also provide the received signal to downsamplenode 2116 via asynchronous wire 2115, where the downsample node 2116 mayoperate to downsample the received signal by a factor of 2, and transmitthe resultant downsampled signal over asynchronous wire 2117 to delaynode 2116. Note that the delay node 2118 is initialized with 150 values(samples), and may operate to provide 1 sample at a time to the mergenode 2112, introduced above. Thus, the merge node 912 may receive datafrom asynchronous wires 2119 and 2111, and interleave samples togenerate the signal transmitted on asynchronous wire 2113, as describedabove. Note that merge node 2112 illustrates a sink (merge node 2112)with two sources (split node 2110 via asynchronous wire 2111, and delaynode 2118 via asynchronous wire 2119). Note also that nodes 2112, 2114,2116, and 2118 form a cycle via respective asynchronous wires 2113,2115, 2117, and 2119, which is not supported in standard data flowdiagrams, thus, as noted above, the asynchronous wires may facilitate oraccommodate non-data flow behaviors.

FIG. 23 illustrates one embodiment of asynchronous communicationmechanisms used in the downsample nodes of FIG. 21. More specifically,FIG. 23 illustrates use of a queue, a FIFO structure, for receiving datafrom an asynchronous wire, and providing data as output to anotherasynchronous wire.

As shown, a downsample node, whose functionality is illustrated in thetop block diagram 2308 of FIG. 23, has access to a queue reference viathe incoming asynchronous wire, denoted as QRef. The node preferablyaccesses and reads data from the queue of the input asynchronous wireusing a dequeue process implemented in a dequeue block 2304, a detailedview of which is illustrated in the bottom left block diagram 2310 ofFIG. 23. For example, in one embodiment, the (bottom left) block diagram2310 receives a reference to a dequeue function of the queue and invokesthis dequeue function to read values from the queue. The output readvalues may then be output, as indicated by the output Array shown on theright side of the block diagram 2310, and provided as input for use bydownsample code 2308 included in the block diagram. Note that values maybe read from the queue singly, or in multiples, as desired. Once thesignal has been downsampled by the downsample code 2308, the results maybe provided to an enqueue process for output on the exiting asynchronouswire, as described below.

Similarly, to transmit data as output onto the asynchronous wire exitingthe downsample node, the node may access and write data to a queuereferenced by an output queue reference, denoted in the top blockdiagram as QRef Out (see far right of the block diagram). The nodepreferably accesses and writes data to the queue of the outputasynchronous wire using an enqueue process implemented in an enqueueblock 2306, illustrated in the bottom right block diagram 2320 of FIG.23. For example, in one embodiment, the (bottom right) block diagram2320 receives a reference to an enqueue function of the output queue andinvokes the enqueue function to write values to the queue. The values tobe written to the queue may be provided in the form of an input array,as indicated by the input Array shown on the left side of the blockdiagram. Note that similar to the dequeue process, values may be writtento the queue singly, or in multiples, as desired. Writing the data tothe output queue thus places the data on the exiting asynchronous wirefor transmission to a node connected to the other end of theasynchronous wire.

While the example asynchronous wires/terminals presented above usequeues, it should be noted that any other types of data structure may beused as desired, e.g., other FIFO structures, stacks, graphs, arrays,lists, and so forth.

Although the embodiments above have been described in considerabledetail, numerous variations and modifications will become apparent tothose skilled in the art once the above disclosure is fully appreciated.It is intended that the following claims be interpreted to embrace allsuch variations and modifications.

1. A computer-implemented method, comprising: utilizing a computer toperform: displaying a diagram on a display, wherein the diagramcomprises a plurality of icons that are connected by wires, wherein theplurality of interconnected icons visually represents functionality ofthe diagram, and wherein the diagram is executable to perform thefunctionality, wherein said displaying the diagram comprises displayinga first wire in the diagram, wherein the first wire connects a firsticon and a second icon; receiving user input selecting the first wirefor configuration of data exchange semantics for the first wire;displaying a graphical user interface (GUI) specifically for theconfiguration of data exchange semantics for the first wire forselection of buffer policy specifying how data are buffered whentransferred between the first icon and the second icon; receiving userinput to the GUI specifying desired data exchange semantics for thefirst wire, wherein the user input specifying the desired data exchangesemantics specifies buffering of data between the first icon and thesecond icon, wherein the user input specifying the desired data exchangesemantics specifies how data are buffered using an intermediate datastore when transferred between the first icon and the second icon;configuring the first wire with the data exchange semantics specified bythe user input; and executing the diagram, wherein during said executingthe diagram, data is transferred from the first icon to the second iconaccording to the data exchange semantics configured for the first wire.2. The method of claim 1, wherein said receiving user input specifyingthe desired data exchange semantics for the first wire comprises:receiving user input selecting the first wire; displaying a graphicaluser interface which displays information useable to configure dataexchange semantics for the first wire; and receiving user input to thegraphical user interface.
 3. The method of claim 1, further comprising:specifying a data transport protocol for the first wire, wherein saidspecifying the data transport protocol specifies a technique forimplementing the data exchange semantics for the first wire, and whereinduring said executing the diagram, the data transport protocol performsthe data exchange semantics specified by the first wire.
 4. The methodof claim 3, further comprising: adapting the data transport protocol tothe data exchange semantics, wherein said adapting combines programlogic with the data transport protocol to implement the data exchangesemantics.
 5. The method of claim 3, wherein the data transport-protocolcomprises one or more of: TCP/IP; USB; DMA (direct memory access); orregister access.
 6. The method of claim 1, wherein the diagram comprisesa data flow diagram, wherein the icons represent functions, and whereinthe wires indicate that data produced by one icon is used by anothericon.
 7. The method of claim 1, wherein at least a subset of theplurality of icons each represent a respective processing element, andwherein each processing element has an associated program for executionby the processing element.
 8. The method of claim 1, wherein saidconfiguring the first wire comprises configuring one or more queues forthe first wire.
 9. The method of claim 1, wherein said configuring thefirst wire comprises configuring one or more buffer sizes for the firstwire.
 10. The method of claim 1, wherein said configuring the first wirecomprises configuring one or more read or write policies for the firstwire.
 11. The method of claim 1, wherein said configuring the first wirecomprises configuring asynchronous behavior for the first wire.
 12. Themethod of claim 1, wherein said configuring the first wire comprisesspecifying a graphical program for the first wire, wherein the graphicalprogram is executable to implement the data exchange semantics; whereinthe graphical program comprises another plurality of icons that areconnected by other wires.
 13. The method of claim 1, wherein the firstwire indicates that data from the first icon is provided to the secondicon, and wherein the first wire also indicates that data transportstatus information is provided from the first icon to the second icon;and wherein during said executing the diagram, the first wire providesthe data and the data transport status information from the first iconto the second icon.
 14. The method of claim 1, further comprising:determining a physical data transport medium based on physicalconnectivity between the first icon and the second icon.
 15. Anon-transitory computer accessible memory medium comprising programinstructions for creating a diagram, wherein the program instructionsare executable to: display a diagram on a display, wherein the diagramcomprises a plurality of icons that are connected by wires, wherein theplurality of interconnected icons visually represents functionality ofthe diagram, and wherein the diagram is executable to perform thefunctionality, wherein said displaying the diagram comprises displayinga first wire in the diagram, wherein the first wire connects a firsticon and a second icon; receiving user input selecting the first wirefor configuration of data exchange semantics for the first wire;displaying a graphical user interface (GUI) specifically for theconfiguration of data exchange semantics for the first wire forselection of buffer policy specifying how data are buffered whentransferred between the first icon and the second icon; receive userinput to the GUI specifying desired data exchange semantics for thefirst wire, wherein the user input specifying the desired data exchangesemantics specifies buffering of data between the first icon and thesecond icon, wherein the user input specifying the desired data exchangesemantics specifies how data are buffered using an intermediate datastore when transferred between the first icon and the second icon; andconfigure the first wire with the data exchange semantics specified bythe user input; execute the diagram, wherein during execution of thediagram, data is transferred from the first icon to the second iconaccording to the data exchange semantics configured for the first wire.16. A system for creating a diagram, the system comprising: a display;one or more processors; and a memory medium, wherein the memory mediumstores program instructions executable by the one or more processors to:display a diagram on a display, wherein the diagram comprises aplurality of icons that are connected by wires, wherein the plurality ofinterconnected icons visually represents functionality of the diagram,and wherein the diagram is executable to perform the functionality,wherein the displayed diagram comprises a first wire in the diagram,wherein the first wire connects a first icon and a second icon; receiveuser input selecting the first wire for configuration of data exchangesemantics for the first wire; display a graphical user interface (GUI)specifically for the configuration of data exchange semantics for thefirst wire for selection of buffer policy specifying how data arebuffered when transferred between the first icon and the second icon;receive user input to the GUI specifying desired data exchange semanticsfor the first wire, wherein the user input specifying the desired dataexchange semantics specifies buffering of data between the first iconand the second icon, wherein the user input specifying the desired dataexchange semantics specifies how data are buffered using an intermediatedata store when transferred between the first icon and the second icon;configure the first wire with the data exchange semantics specified bythe user input; and execute the diagram, wherein during said executingthe diagram, data is transferred from the first icon to the second iconaccording to the data exchange semantics configured for the first wire.